Purposeful Design Principles for Behavior Change
How to design products and services that help users change behavior
Steve Wendel (@sawendel) is the Principal Scientist at HelloWallet where he develops applications that help users take control of their finances. He’s also currently writing Designing for Behavior Change. I recently sat down to talk with Steve about the importance of testing and iteration, role of psychology, and resources and tools.
Key highlights include:
From BASIC to HyperTalk to JavaScript to Rails to Erlang
Every programming experience teaches
I’ve never formally trained to be a programmer, outside of occasional conference workshops and a week of XSL tutorials. In some ways, that’s terrible, because it’s taken me about thirty years to learn what some friends of mine appear to have learned in four. I’ve written some code that goes way beyond spaghetti, though fortunately the worst of it was probably when I was 15.
On the bright side, when I look past my many mistakes, I can see what I learned from a large number of various different experiences, and the pieces they helped me see. It’s a little easier to tell this story through the parts than it might be through a formal curriculum.
- My parents’ FORTRAN books
- I was reading computer books—dry ones—before I even got to play. I have vague memories about program structure, but mostly I learned that knowledge sticks better if it includes hands-on work, and not just a book.
- Sinclair ZX81
- 1K of memory! The sheer thrill of seeing my creations on screen was amazing. I had just enough logic to get things done, and leave myself puzzled. The Sinclair community seemed focused on making great small things. I learned simple logic in BASIC and that sometimes it takes a hack to get things done.
- Applesoft BASIC
- After Sinclair BASIC, Applesoft seemed vast. Much of what I did was transfer what I’d done on the Sinclair (itself a lesson in platform-shifting). As I settled, I started writing larger and larger programs, eventually forcing myself to restructure everything into subroutines…with global variables, of course.
- 6502 Assembly
- I knew there was more than BASIC. My early adventures with assembly language were mostly about graphics, and didn’t work all that well, but I picked up two key things: recursion and the importance of registers.
Upward Mobility: Overly Defensive Programmer
Sometimes, the best defense is a good offensive core dump
By now, most meme-aware internet surfers have encountered Overly Attached Girlfriend (and the Rule 63 counterpart, Overly Attached Boyfriend.) What isn’t as well known is that they have a brother, Overly Defensive Programmer (ODP, for short.)
ODP is a mobile developer who lives in the constant fear that the server-side folks are going to subtly change an API out from under him, making his app crash. To avoid this, he puts in code like this:
NSError *error;
NSDictionary *responseData =
[NSJSONSerialization JSONObjectWithData:data
options:0 error:&error];
if (error != NULL) {
// All sorts of logging code, followed by returning
// from the call silently, swallowing the error
}
if ((responseData[@"payload"] != NULL) &&
(responseData[@"payload"][@"objectId"] != NULL)) {
self.objectId =
((NSNumber *) responseData[@"payload"][@"objectId"].intValue;
}
We’ve all seen code like this. The developer didn’t want to accidentally cause a fatal error by trying to get the objectId parameter if the payload was missing, or to try accessing the objectId if it was missing. And if objectId is an optional field, this is totally the way to go.
The thing is, objectId sounds like it is probably a critical piece of data, without which the application will fail to operate properly. You want the application to crash if it goes missing, because that means it will crash during QA testing, rather than silently ignoring the problem and possibly malfunctioning in a way that QA misses.
Read more…
Hot Swap Devices and Increase Arduino Interface Options with I2C
Don't be afraid of the bus
After a short period of time, beginners working with the Arduino development boards often find themselves wanting to work with a greater range of input or sensor devices—such as real-time clocks, temperature sensors, or digital potentiometers.
However each of these can often require connection by one of the two digital data buses, known as SPI and I2C. After searching around the Internet, inexperienced users may become confused about the bus type and how to send and receive data with them, then give up.
This is a shame as such interfaces are quite simple to use and can be easily understood with the right explanation. For example let’s consider the I2C bus. It’s a simple serial data link that allows a master device (such as the Arduino) to communicate with one or more slave devices (such as port expanders, temperature sensors, EEPROMs, real-time clocks, and more).
Read more…
Using XSLT 2.0 as a Web Scripting Language
Stunning JavaScript implementation suggests more is possible
A language built to support event handling, not strictly a functional programming language but fitting that mold. A deep understanding of markup structures. A home in the browser.
That’s JavaScript, all right—but now, thanks to JavaScript, it is also XSLT. After all the discussion I heard about templates and JavaScript at Fluent and OSCON, starting with a language built on templates seems like a better and better option.
Thursday afternoon at Balisage, O’Neil Delpratt and Michael Kay discussed Interactive XSLT [2.0] in the browser, showing not just the usual transformations but a working engine for a graphical interface. Their earlier XML Prague paper also tells the story and shows more code detail, including a chess game.
Read more…
Can Markup Unite?
Getting past the HTML / XML splits
A few years ago, I stopped talking about XML and starting talking about markup. After a few too many conversations with developers who had found XHTML, web services, and various other things that had proudly branded themselves with the “X,” it was clear from hostile responses that XML’s boom was done.
Many of Wednesday’s Balisage talks wrestled with the challenges XML tools face in a world dominated by competitors, especially HTML5. Today opened with a talk on making XForms work in HTML5 with browsers, followed immediately by a talk on replacing DocBook XML with XHTML5 (at O’Reilly). Two more abstract talks looked at filtering and an info space model, but the afternoon asked “Where did all the document kids go?” and then sought world domination by making XML invisible.
The Open Compute Project
You Are Invited to Optimize Computer Infrastructure
Jay Parikh (@jayparikh) is VP Infrastructure, Facebook. We talk about where The Open Compute Project has been and where it is going! For more information check out The Open Compute Project website.
Key highlights include:
- Find out about the Open Compute Project [Discussed at 0:13]
- It’s all about open hardware [Discussed at 1:10]
- Facebook data centers have been optimized [Discussed at 2:12]
- How do you get involved? [Discussed at 3:33]
You can view the full interview here:
Can We Do Better Than XML and JSON?
FtanML looks for the best of both
Today’s Balisage conference got off to a great start. After years of discussing the pros and cons of XML, HTML, JSON, SGML, and more, it was great to see Michael Kay (creator of the SAXON processor for XSLT and XQuery) take a fresh look at what a markup language should be.
Many recent efforts have been reductions. JSON was an extraction from JavaScript. XML was a simplification from SGML. MicroXML pushes simplification much further. Reductions are great for cleaning up past practice and (usually) making tools more accessible, but genuinely new features come later, if at all. The JSON and XML camps mostly stare at each other warily, and though people mix them, there’s little real “best of both worlds.”
The Rise of Infrastructure as Data
Simplifying IT automation
IT infrastructure should be simpler to automate. A new method of describing IT configurations and policy as data formats can help us get there. To understand this conclusion, it helps to understand how the existing tool chains of automation software came to be.
In the beginnings of IT infrastructure, administrators seeking to avoid redundant typing wrote scripts to help them manage their growing computer hordes. The development of these inhouse automation systems were not without cost; each organization built its own redundant tools. As scripting gurus left an organization, these scripts were often very difficult to maintain by new employees.
As we all know by the huge number of books written on the topic, software development sometimes has a large amount of time investment required to do it right. Systems management software is especially complex, due to all the possible variables and corner cases to be managed. These inhouse scripting systems often grew to be fragile.
Upward Mobility: To Storyboard or Not to Storyboard
That is the question for iOS developers
Storyboarding was introduced in iOS 6, and it offers a way to consolidate all of your disparate Interface Building files into a single overarching whole. Although it’s tempting to jump on board and use it just because it’s the new thing, there are some things to keep in mind.
- Storyboards require you to make the jump to iOS 6; there’s no backwards compatibility for earlier versions. While this isn’t as much of a factor as it was a year ago, if you have legacy iPad 1 customers, you’re going to be locking them out of your app if you move to storyboarding.
- Having all your XIB files consolidated may sound good, but if you have a lot of them, you can end up with a new storyboard that’s so big that it is unwieldy.
- Storyboards are more than just a consolidation move; you also have to adopt a whole new programming style to move between your screens. Instead of explicit pushes and pulls off of view controller stacks or opening of modals, you are firing off segues that cause new view controllers to be created and transitions to occur.
The last point isn’t a bad thing per say. It’s a much more MVC-like paradigm: for example, where the overall controller knows what a transition means, and the individual views are only responsible for requesting a transition. It’s also much more like the way that Android does things. But it’s a different style of programming from traditional iOS UI development, and has a learning curve associated with it.
Read more…
