By now you've seen the news: Osama Bin Laden is dead.

While this is an important symbolic milestone in the war against the emotion known as terror, I have to admit I am a little put off (though sadly not surprised) by the unabashed and ghoulish treatment of this subject by my fellow Americans both in the popular media and and in the mainstream media. I heard commentators on MSNBC speak of the satisfaction in knowing that he was shot to death instead of merely killed by a drone or in a missile attack. There was footage of students in alcohol-fueled gatherings at the gates of the white house, at ground zero, in Beaver Canyon. And Twitter, in particular, seems to be particularly flooded with endless OBL-tech-social-media jokes, virtual high-fiving, lolcat style pictures, and numerous obscure-but-clever references designed to let people know "Hey, did you hear that OBL is dead? I'm telling you via this oh-so-witty internet reference. Its OK to laugh about it now because we're OK...". 

As if it was a football match.

Any commentary pointing out this ghoulish behavior is immediately, and unmercifully, met with challenges to the plaintiff's patriotism, and questions such as "Isn't the world better off with OBL dead?" or "Should we have not killed Hitler too?". Its like its 2003 all over again. If you point out your discomfort with the idea that killing is the solution to any problem, suddenly you have become as bad as Bin Laden himself.

I can't really say whether or not the world is better off now that The Enemy of the State is dead. I can't say whether we shouldn't have killed him, or whether we should have tried to take him captive to spend the rest of his life behind bars. But I can say this: indulging in adolescent revenge fantasies and ghoulish revelry of a death, even when the subject is deemed to be an enemy of The People, is ... outside of my system of values. 

I looked at the (exclusive) pictures and read the accounts of OBL's last stand. It was incredibly brutal. As war should be. I can understand that this is a sort of catharsis for the American people, and there is a collective sense of relief (albeit misguided -- nothing has changed), but I think that the best thing to do is to acknowledge it with some amount of solemn reflection and move on. Not turn it into an excuse for a party in Beaver Canyon.

I know I am in the minority in these thoughts, which is why I told you not to read them. Go ahead and comment if you're all riled up by my words, but also know that whatever you say isn't going to change my point of view.

edit to add a link to a Salon article that says this way better than I can: http://www.salon.com/news/politics/war_room/2011/05/02/osama_and_chants_of_usa/index.html

The Connectivist LMS

This post is a reaction to Connectivism: A Learning Theory for the Digital Age, by George Siemens (2004).

What if the Constructivists are not quite correct in thinking that learning occurs within the individual, as he interacts across the zone of proximal development with a social peer who is more experienced in a given domain? Should we consider learning as something that occurs solely in the individual, and assign its value accordingly as a process of personal gain? Or is the value of learning perhaps more Newtonian in nature, with both parties to the transaction experiencing a net gain as a result of the process? And if we consider that the value of this negotiated knowledge may reside between individuals rather than within them, what does that say about our design of (and relationship to) technology as a means of enabling learning?

In his theory of Connectivism, Siemens states "Learning is a process that occurs within nebulous environments of shifting core elements - not entirely under the control of the individual. Learning (defined as actionable knowledge) can reside outside of ourselves (within an organization or a database), is focused on connecting specialized information sets, and the connections that enable us to learn more are more important than our current state of knowing." This theory places more emphasis on what you can immediately do with knowledge -- and how learning leads to more learning -- than the constructivist (and perhaps, now that I think of it, mercantilist) conception of knowledge as something that is stored for later use. Siemens then uses this concept to address a perceived limitation of current modes of learning -- that knowledge gained has a half life that is growing increasingly ephemeral.

Its an interesting idea, and I recommend reading this article carefully, but what I really want to do in this space is pose the question, "What would a Connectivist learning environment look like?". I have to confess that this question is driven by a few criticisms I have of current learning management systems: 

-They are not very good at creating communities of learning (or even exploiting existing ones in a given domain), 

-The basic building block of the LMS is the course, a logical unit for a bricks-and-mortar teaching and learning operation governed by scarcity of resources (ie seats in classrooms, number of available teaching hours and teachers), however I'm not convinced the concept of the 15 week course is optimal in a paradigm of information abundance (gluttony, even)

-And they operate on the principle that the person running the show (be it faculty or administrator) is a benevolent dictator, knowing what's best for every learner and prescribing a one-size-fits-many approach to learning.

What if:

This is a reaction to Chapters 2 and 3 of Donald Norman's book, "Everyday Design: Why we love or hate everyday things". This is part of an assignment for Design Studio. As I've mentioned before, this reading is part of the Level 1 readings, but since I entered the program beyond Level 1, I am revisiting it to inform my own work.

Begin Reaction:

As I've talked about before, Norman believes that there are three levels of reactions that humans have when interacting with designed objects or experiences, and these reactions dictate the success or lack of success a product has in the chaotic marketplace of ideas, products, and emotions that is life on planet Earth.

In this part of the book, Norman gives more detail about these levels, and offers three corresponding modes of design to provide a framework that designers can work within to achieve success. Not surprisingly, visceral design attempts to persuade the human through appealing to the base, automatic reactions to things, a cappacity we have developed over vast stretches of time through survival and evolution. Behavioral design tries to appeal to our desire for functionality, understandability, and usability. While reflective design gets at our capacity to put some thought into why we use or prefer certain things, and ultimately how we see these things as potential enhancements to our self image and prestige. 

Of course there are two things to keep in mind about this idea of visceral, behavioral, and reflective reactions to experiences and things:

1. These levels overlap, and it is the job of the reflective layer to make the ultimate decision on whether a human will actually purchase and/or use something. Although the reflective layer does not always win. It is important to understand this.

and 2. What we are really talking about here is manipulation and trickery. Whether it is genuinely innocent -- as in the designer who just wants to make a better widget to make his or her own life better (which, incidentally results in the best quality of products overall); or whether it is ingenuous -- as in the store layout designer, who purposely puts the common daily items at the back of the store which can only be reached after passing through a gauntlet of strategically placed impulse-purchase items. Design, to Norman, is the science of manipulating people's emotional and intellectual reactions to achieve the desired outcome: successful products.

The previous paragraph may sound a little harsh, and I don't mean it to be so. This is the way in which the human, as a social animal, copes (quite successfully) with our place in the universe. Norman is merely offering some practical guidance for how to do this in a more scientific, more efficient way. 

The piece that I am choosing to take away from this writing is that as a designer, it is better to expend my focus on creating something that I personally find useful, such as an iPhone app or a web service, than to put the cart of money before the horse of usefullness, which is also quite possible in the space of software development. Ultimately, like every one else, I do want to sell things, even if it is only ideas. Norman's advice is a good starting point for understanding how to become good at doing that.

This is part of an ongoing series of blog posts about developing iOS Apps. Today I want to talk about the wonder and majesty that is Core Data.

When I first started delving into the tutorials on Lynda.com and elsewhere, I very quickly made it to the point where I wanted to store data somehow in the application. The data storage tutorial on Lynda.com was very informative, walking you through how to leverage the built-in capability to store data in a SQLite database, walking you through construction of the database itself, implementation of the lower level C code that interacts with the database (including writing SQL statements), and then sort of providing you with an Objective-C wrapper to make it easier to work with the db. I was a little dismayed at how complex this turned out to be, but looking at a few books, I was seeing the same sort of basic procedures, so I thought "This is what it means to use data on iOS devices".

In truth, this *was* how it was to use data on iOS devices -- until Core Data.

I have a background in Java, and have built a few web applications using Web Objects, Apple's framework for rapid prototyping that never quite saw the widespread adoption it deserved. The way the programmer interacts with the database in Core Data is very similar to Web Objects, so it turned out to be very refreshing when I started getting into iOS programming and came upon some of the same techniques.

As an aside, I spent the Fall 2010 semester digging into Flex, which is incredibly similar to Java programming, and did alot of work setting up applications that talked to various data sources, including MySQL databases and XML feeds. I never liked how up close and personal Flex and PHP programmers have to get with databases. Writing SQL statements and iterating through arrays is tedious work to me. Because of the Model-View-Controller way in which Web Objects interacts with the database, it seemed very unnatural to me to have to deal with those things. Things should go into and come out of databases as objects, or collections of objects.

So how is Core Data different? Well, for one thing, say goodbye to writing SQL statements. Apple has very graciously abstracted that very tedious work away from us. Just as you don't have to know how to build or fix an engine to drive a car (although it certainly helps), you don't have to know anything about databases to use Core Data.

Instead, you now work with Entities, Attributes on entities, and Fetch Specifications. You now also have something called a Managed Object Context that handles all of the actual interaction. The basic workflow is:

• Design rows in your database visually, as objects. Your objects can also have attributes and relationships with other objects. Attributes are like columns in your database, while relationships are like relations. This comes in handy, for example, when you want to load large amounts of binary data, as you can take advantage of something called "Faulting" (as I'll talk about a little later)
• When you want to interact with objects in your database, you ask the Managed Object Context to fetch them for you. You can fetch either all of the objects or just some of them using a Fetch Specification, which is just an object you can set up to specify how to Fetch objects from the db.
• After the objects are fetched, they are held in memory, where you are free to alter, undo, and redo changes on them. When you are ready to commit the changes to the database, you ask the Managed Object Context to save the data.

The following image illustrates how objects are visually defined in the database:

In this example, I have created a photo object to hold metadata about a photo, and an image object to hold the actual binary image data. I then set up a reciprocal relationship between these two objects. The reason I did it this way is to take advantage of a process called "Faulting". 

The basic idea behind Faulting is that memory is at a premium on mobile devices. The actual binary data that makes up an image takes up much more memory than the string data that is collected in the metadata attributes defined on the Photo object above. So wherever possible, we want to represent our object using the metadata object (such as displaying the title in a row in a table rather than using a thumbnail). We use faulting to control when the binary image data is displayed on the screen. Because there is a two-way relationship between the Photo Object and the Image Object, the Managed Object Context knows to only fire that fault when the image data is actually needed (by asking for the Photo.toImage value in the code). Then it removes the image from memory when it is no longer needed, freeing up valuable space.

So this to me is a much cleaner and more logical way to interact with a database. Working with objects also has the benefit of being much cleaner code that is much more tightly coupled to the IDE, enabling you to take advantage of advanced features of Xcode like code completion and refactoring.

There is one problem I ran into though: I found myself in the situation of needing to store an array of CGPoint values in the database. Core Data does not provide any collection data types. I searched around on the web and found that there are a few solutions to this, neither of which was particularly great. 

One solution people do is to use a one-to-many relationship between objects, defining a collection object and then a to-many relationship to a series of more primitive objects like strings or whatever. Since I had to store perhaps thousands of points, I thought this might get a little messy, so my next option was to convert the array into binary data and store it as a binary data type. This took some effort to figure out, but I finally got it working by

Begin Reaction:

Donald Norman puts forth the idea that things (designed objects) tend to work "better" when they are more aesthetically pleasing. He arrives at this conclusion via a neuro-cognitive perspective -- basically that the emotions you experience as a human being change the way you experience the interaction with the object as you are interacting with it. In layman's terms: if you are in a good mood, you are more creative, perhaps choosing alternative paths to achieve a desired result, and more tolerant of difficulties encountered when interacting with an object.

He makes a very plausible argument that there are three levels with which the human brain interacts with the world: The visceral level, the behavioral level, and the reflective level. The visceral level is the mostly unconscious automatic reactions that we have that prepare us to survive any given unknown encounter. The behavioral level controls everyday behavior -- what we do in situations that are not novel. While the reflective level allows us to intellectually exert a finer level of control over the other two, but only after we have determined that we have survived the encounter and have time to reflect on what happened. 

This fits in with what I understand of evolutionary biology. It makes sense that we could have only survived to the present day if we evaluate all new encounters with a sort of 'fight or flight' preparatory suspicion. Over the millennia, we animals have developed an innate sense of which sensory experiences generally promote survival (warm fuzzy things) and which ones potentially threaten it (sharp pointy things). 

However, what I believe is that because humans have language and the ability to educate successive generations, the survival oriented benefits of the visceral reaction to everyday things has become diluted over time. Norman explains this in relation to design in that our visceral reaction is manifested as emotion related to products, and one that we cannot always necessarily explain. What is interesting about this is Norman's assertion that the visceral level still usually wins in any given situation. What this means is that sometimes even when we consider all the variables, we still like things for reasons that may not be entirely logical. Norman's idea, then, is that if we can design objects with properties that exploit this emotional connection, we should have a better chance of success in whatever it is we are trying to achieve through the design we are creating.

Apple understands this and is currently exploiting it (along with being first to market) to mop the floor with its competitors. Consider the case of the iPad or iPhone vs. any supposedly technically superior Android device. Apple made their devices so pleasing to use, from the design of the hardware (with features like rounded corners) to the experience of using the software (pleasing sounds and feedback, intuitive buttons, large pleasing interface elements, satisfying touch gestures) that it doesn't matter if the hardware capabilities of some of their competitor's products are technically superior. The experience of using an iPad puts us in a good mood, and therefore we prefer to use it. That is not to say that the logical reflective part of our brain can't overcome this -- after all, some people still buy Android tablets (and some people keep snakes and spiders as pets). 

The lesson to take away here is that considering your audiences' emotions as they use the thing you are designing can pay enormous dividends. I look forward to reading more of Norman's book to learn how to achieve this in future designs that I participate in creating.

If you don't think too deeply about it, it doesn't seem like that big of a deal. You might think "We could just work on different parts of the code and then elect one person to put it all together" or "We could just throw the files up on the web-server, that's where they're going to end up anyway". And yes, that might work to some extent, but what if you are working on code that doesn't ultimately go on a webserver, and what if you are trying to take an object oriented approach where there are tens or even hundreds of classes. It would be very difficult to manage which programmer 'owns' which classes, and which version has the latest set of all the classes, and what if the programmers want to actually work on the code at the same time? This last question poses an interesting problem, namely, if Programmer A and Programmer B each are writing code at the same time, and they upload their changes to the server, which version is the correct version? The answer to all of these questions, in the absence of a source code repository is unclear.

This is where SVN comes in. You can think of SVN as both a location where the project actually lives -- ie file space on a server -- and also as a sort of gatekeeper for changes to the code. SVN the gatekeeper allows users to check the code in and out of SVN the repository, and when you do that, it gives you the tools you need to ensure that you are working on the latest version of the code (the latest to be checked in) and it resolves any conflicts that may come up when you are done working on your little piece of code and want to check it back in. If you do any kind of coding in the real world, you are likely going to run into SVN at some point.

A typical (simplified) workflow for someone using SVN might look like this:

Getting started requires overcoming a few obstacles, technically and mentally. In no particular order, here was what stood out to me as challenging in the first few weeks:

This post is a reaction to Heidegger's "Questioning Concerning Technology"

I chose to reflect on this article because I think Heidegger puts into words a lot of the thoughts that a student of design should be having. It was written in the 1950's, after the invention and use of nuclear weaponry by "the good guys", and the revelations of the horrors of the holocaust perpetrated by "the bad guys" (to which Heidegger was likely connected, although to what extent scholars are unsure). To sum up a very dense piece of reading, Heidegger is concerned with understanding the essence of technology in order to understand the 'why' connected with it. Humanity, to that point had already become adept at demonstrating the 'what' and the 'how' of technology.

The 'what' and 'how' piece positions technology as a means to an end, an instrumentality dependent on 4 (semi-Aristotelian) causes:

The material it is made of, the physical dimensions or final form of it, the purpose for which it is made, and the intent of the creator of the thing. These are all things that a designer is concerned with when creating something. Heidegger didn't disagree with this definition, but argues that it doesn't go far enough. To Heidegger, the key to technology is that it is the thing that humanity uses to understand the universe as it reveals itself to us. Understanding the 4 causes isn't sufficient to understand technology because it implies a certain pre-existence which doesn't agree with the idea of invention, nor does it impart a sense of responsibility for use of the technology. Technology is seen as a mere means to an end.

Heidegger is concerned with technology because he sees in it a grave danger, the enablement of the self-destruction of humanity. This is in contrast to most people's conception of technology. Most people would admit the destructive potential of particular things they learn to be destructive, such as bullets and bombs, but may not see the same destructive potential that Heidegger might see in something like a hydroelectric dam, a silver chalice, or a mainframe computer. The danger in the use of technology is not just limited to explosions, but more so the idea that humanity is reduced to the status of a resource and therefore becomes enslaved by the very thing that is supposed to be helping us.

The answer to this question of danger, to Heidegger, lies in the role of the craftsman or artist, or designer. Art and design is an exploration of the unfolding of reality, without the destructive-consumptive aspect of modern technology. This ties in nicely to Hokanson et al's conception of the balance that is needed in role-based design between commodity, firmness, and delight. Thinking about it this way, this says to me that our designs do not necessarily need to always be productive, efficient, and technically resilient, and in fact the more we can deviate from these qualities, the better off we will all be. We should always keep in mind the 'why' as well as the 'how' and the 'what'.

I end with a quote that always stuck with me from the movie "Slacker", which was important in my formative years: "Every single commodity you produce is a unit of your own death".

You can visit the site and try this yourself. It does require a plugin, and you have to print a camera and have a webcam, but if you have all that stuff, you should be good to go. There is also a much better video on the site linked above if you don't want to or can't try it for yourself.

Or you can download the movie here: AR Olympus Demo.m4v

Obvious uses for this kind of tech are for demoing consumer objects, but this could also be used in teaching and learning. Off the top of my head, creating atoms and molecules that a student can manipulate virtually could be very useful for learning concepts in chemistry.

The following is a reaction to Role Based Design: A contemporary perspective for innovation in instructional design, an article by Hokanson, Miller, & Hooper (2008):

This article expands upon (or perhaps is expanded upon by) the book chapter "Commodity, Firmness, and Delight: Four Modes of Instructional Design Practice" by the same authors. In this article the authors present a more detailed look at the concept of role-based instructional design. 

The basic idea is that as designers, our perceptions of our work guide our own practice. This can be roughly described according to a number of different archetypes, each concerned with a slightly differing aspect of the instructional design process: The manufacturer (concerned with efficiency of production), the engineer (concerned with function), the artist (concerned with playful experimentation), and the craftsperson (concerned with perfecting the craft). As a result of the imbalance of methods of these archetypes, the field of instructional design has become somewhat stagnant in terms of innovation, the authors contend. This leads to design that is technically or pedagogically competent, but lacks the extra something that would move the product to the next level: that of the designed experience.

What would design look like if, as designers, we took a more holistic approach, incorporating aspects of all of these -- letting each one drive when appropriate  -- instead of letting any one archetype dominate because it fits with our personality, mission constraints, education, personal style etc.? Further, what would the field of design look like if we trained designers to draw upon the balanced form of these archetypes rather than the production oriented ADDIE model?

--Interesting sidebar: I like how the authors describe ADDIE as an after-the-fact model, meaning it was developed by watching what ID's do rather than by thinking through the best way to do something and devise a model based on that. --

Its hard to imagine what this would look like, particularly in the context of a business. The reason most instructional design trends toward manufacturer/engineer probably comes from the need to develop instructional materials in the context of a profitable enterprise due to the high cost of developing reasonably good instructional materials. However it is seductive to think that given enough resources (perhaps even just a little more than currently allocated to design endeavors), design could possibly be taken to the next level, allowing for experiences that delight students as we as being technically and pedagogically competent.

Perhaps this is where concepts such as Open Educational Resources and Reusable Learning Objects can prove to be helpful. What if a designer took existing material from an open repository and mashed it up with newer materials? Would this free up some room for some of the more neglected archetypes such as the artist or the craftsperson to play? Might this bring more balance to the field of instructional design?

End Reaction. WC: 450