TECH 637: A reflection

This was definitely an interesting class to take for my first semester of graduate school.  It was hard.  I can’t say I wasn’t warned beforehand, because the expectations of the course were made clear from even before I signed up.  The biggest paradigm shift for me was that there was far more reading and writing than I had ever had in any course ever.  To put it in perspective, most of my courses in undergrad were technical in nature, so I spent much more time writing programs and making 3D models than dissecting research papers and writing literary analyses.  Students in the liberal arts are probably giving me a very knowing look right now.  Message received.  Even though it seemed like a Sisyphean task, I managed to emerge on the other side with the knowledge that, like code and UIs, there are design patterns to research articles as well.

This course also didn’t disappoint in delivering on its titular subject: the social internet.  Through the course of the semester, I was introduced to topics like crowdsourcing, the nature and composition of social networks, self-organization, identity in digital spaces, and contemplative computing.  It was an inspiring whirlwind tour, and I learned, forgot, and re-learned an astonishing number of things.  Don’t quiz me on them right now, though.

Another aspect of the course that interested me almost as much as the content was that the format was very firmly grounded in what I think is called an inverted classroom.  People who know these things: here you have found someone who is probably wrong on the internet, so please set him straight.  I was interested to see how such a class would actually be delivered, and I was both surprised and pleased.  I very much enjoyed the focus on reflection, as it really forced me to extract the meaning behind the verbose and formidable disbursement of knowledge that I was reading.  Making this activity take place in shifting configurations of small groups really helped develop a sense of community among the class, which was also something that I have rarely seen in other courses.

To my classmates who are reading this: keep on being awesome.  We all know you are.  Thank you for putting your best effort into making the class such a unique and fun experience.  I hope that writing the final paper hasn’t driven you insane, because that would just be an ironic end for your pursuit of greater knowledge.  Just don’t go there.  Instead, tackle every day with the same wit and charm that you showed every monday night.

The Aftermath of Leaving

I was in a discussion the other day that briefly touched on the question of “What happens to online presence when people die?”.  That got me thinking about a parallel question of what happens to online celebrities when they try to leave the internet.  I’d been reading  an article recently about the prolific Ruby developer, Jonathan Gillette, or _why, and I was intrigued not just by his disappearance, but how the Ruby community reacted in the aftermath.

The desire to disappear from the grid isn’t new by any means, but the nature of the internet has made it play out in some very interesting ways.

Core Followers

I’m pretty new to Twitter, but I have already found a little bit of why people love it so much.

When I first opened my Twitter account, I really didn’t know who to follow.  Not in a ‘is it rude to follow people you don’t know’ way, but more that I didn’t know how to tell who where good people to connect with.  However, since I’m primarily a software developer, I decided that my first picks from the professional sphere would be some of the core team behind the JavaScript framework that I’m getting into, Ember.js.  It’s been a really great door into the minds of the people that made software that I love.

Currently, that list includes Yehuda Katz (@wykatz), one of the creators of things like Ruby on Rails, JQuery, Ember.js, and Handlebars, who still has mythical figure status in my mind, Trek Glowacki (@trek), a developer at Groupon who has written more excellent Ember tutorials than anyone else I can think of, and Tom Dale (@tomdale), the other co-founder of Ember.js, who is just mentioned so much by everyone else that he seemed like a good choice to follow.  I found out later that he also writes excellent blog posts.

They tweet their thoughts about the web and JavaScript, code snippets to solve specific problems, and random quotes from whatever is going on.  More than just what they tweet, they also retweet a lot of other prominent developers.  It is the only way I could possibly keep track with the things the community as a whole is discussing and working through.  The newest issue, just in case you were wondering, is whether Progressive Enhancement (the idea that you should build web pages and apps for the lowest common denominator and add functionality) is a practical idea and to what extent is it worth implementing any more.

In short, thank goodness for people who are informed and share their knowledge, because it’s been invaluable for me.

Robots Making Robots: Continuous Integration for Non-Developers – Part 1

I was recently discussing what made Web2.0 so different from 1.0, starting from the seminal article by Tim O’Reilly. Since the article was written in 2005, most of the defining characteristics, like rich media on the web, multi-device services, and data-driven applications are a familiar and natural part of my life at this point. However, I work every day with a fascinating part of Web2.0 that is still rapidly evolving in the business world: the Perpetual Beta, the process of which is now known as Continuous Integration.

In traditional software development environments, people would make a piece of software by figuring out what it needed to do, doing the work to actually make it, and then releasing the software so that you could buy a copy and install it. The Windows operating system is a great example. I remember when there was only Windows 98, but then Microsoft released Windows, XP, Vista, 7, and now 8. There are distinct releases of Windows, and you have to install that release yourself to use it. Even when you have automatic updates, you still need to restart your computer for it to get all updated. Also, there are people now that still have Windows 98 while someone else has the beta version of Windows 8.1. On the other hand, while the look and features of Facebook has changed over the years, you’ve never had to upgrade from Facebook XP to Facebook 7, and everyone uses the same Facebook. It just happens completely automatically.

These two opposing sides are essentially the two extremes of how you get software. Your operating system is as fundamental to your computer as you will probably ever care to go, so it’s like the foundation of a skyscraper: you can only build so far up before you need a better foundation to do any more. However, the web is like your favorite restaruant in the skyscraper: whenever you want to get some pan-seared salmon with lime and decorative veggies, the waiter brings you a whole new copy of the dish every time, and the chef could improve on his recipe from visit to visit and you wouldn’t have to do anything more to get the benefit of it.

Spurred on by the popularity of smartphones and of people being connected to the internet almost 24/7, all software development has started to move towards how the internet does it naturally. The apps on your phone now download updates in the background and then install them as soon as you’re not using the app any more. The app store lets this happen by making sure you, your bff, and your cat all have the newest version of Instagram on your phones so that you can share pictures of what food you just ate. Apple has popularized this in the desktop world with the Mac App Store. Now you just have to find the page for Angry Birds and click install, and the Mac App Store takes care of the updates for you.

In a nutshell, Windows 98 had some security patches throughout the years, but the Windows experience was essentially the same until XP came along and everything changed, whereas now, Amazon doesn’t drop entire redesigns of the Amazon store any more, but it tests and changes little things all the time to improve what you can do and how enjoyable it is a little bit at a time. Does a blue ‘Buy Now’ button get more sales, or does the green one? Do people buy more extra things with five related products shown after a purchase or four? This philosophy of developing by updating software very quickly even after it’s been released is what Tim O’Reilly called the Perpetual Beta, and the tools and processes that make it possible are now collectively called Continuous Integration. In the next part of this series, we will take a look at the major types of tools that make Continuous Integration possible, and why they’re so needed and so great.

Emotional Design

I came across an interesting article from the Focus Labs blog:

I always enjoy articles that focus on the psychology of user-centered design, because they always challenge me to reflect on my own design practices.  In the article, Sam Stratton talks about the emotional component of interactions being a catalyst to desire to produce things of value.  To me, this seems to ring true with what I know of interaction design.  There is a strong internal desire you’re tapping into: the need to feel wanted, and investing time into producing something valuable ideally gives a strong positive feedback: the approval of your peers.

I’d like to hear your thoughts.  Is a positive feedback mechanism for an emotionally-based interaction something that requires a response from a person to provide appropriate closure, can the interface giving the equivalent of a “Great job!” be sufficient, or is there still another way to keep the feedback loop going strong?