Last night, a friend of mine, was riding her bike along Kimball near Wrightwood. A purplish-maroon Chevy Tahoe pulled up alongside her. The passengers leaned out and grabbed her by her messenger bag and dragged her as the car sped laughing and yelling at her all the while.
The nightmare stopped when eventually she crashed into a parked car that finally pulled her away from her the hands of her attackers. By some miracle, she was only bruised and terrified.
The Chevy Tahoe and the amused sadists sped away before she could get their license number. Compassionate witnesses and drivers stop to check in on her and help her phone a friend who escorts her to the hospital where she’s released at 4am.
This isn’t all that unusual. Lately there have been a rash of attacks on cyclists in Chicago.
The latest one happened to a friend, and one of my favorite Chicagoans, Jana Kinsman. If you’re a Chicagoan, you might know her, she’s a beekeeper, illustrator, urban naturalist, and very active member of Chicago’s design community.
Please reblog. I don’t ask people to do that often, but I have to believe that maybe someone, somewhere in Chicago knows something that can help out. There are people out there who are trying to kill people for fun.
In her words, “What makes me feel most helpless is that i can’t be like ‘learn from this’. I can’t offer anything. This is that awful tiny fraction of bike injuries where there was nothing i could have done different to avoid this.”
“If you hate your parents, the man, or the establishment, don’t show them up by getting wasted and wrapping your car around a tree. If you really want to rebel against your parents: outlearn them, outlive them, and know more than they do.”—Henry Rollins (via selenarox)
“Man is, at one and the same time, a solitary being and a social being. As a solitary being, he attempts to protect his own existence and that of those who are closest to him, to satisfy his personal desires, and to develop his innate abilities. As a social being, he seeks to gain the recognition and affection of his fellow human beings, to share in their pleasures, to comfort them in their sorrows, and to improve their conditions of life. Only the existence of these varied, frequently conflicting, strivings accounts for the special character of a man, and their specific combination determines the extent to which an individual can achieve an inner equilibrium and can contribute to the well-being of society. It is quite possible that the relative strength of these two drives is, in the main, fixed by inheritance. But the personality that finally emerges is largely formed by the environment in which a man happens to find himself during his development, by the structure of the society in which he grows up, by the tradition of that society, and by its appraisal of particular types of behavior. The abstract concept “society” means to the individual human being the sum total of his direct and indirect relations to his contemporaries and to all the people of earlier generations. The individual is able to think, feel, strive, and work by himself; but he depends so much upon society—in his physical, intellectual, and emotional existence—that it is impossible to think of him, or to understand him, outside the framework of society. It is “society” which provides man with food, clothing, a home, the tools of work, language, the forms of thought, and most of the content of thought; his life is made possible through the labor and the accomplishments of the many millions past and present who are all hidden behind the small word “society.”—
Setting up a Static Blog on OS X to Publish to S3 [UPDATED]
WARNING: This is rather a technical post. If you’re not comfortable doing neckbeardy things like typing stuff at the Unix command line and adding stuff to your bash profile, you probably want to give it a miss.
All I wanted to be able to do was write posts in Markdown in a Dropbox folder and have them be automatically published as a static blog hosted on Amazon S3. On a Mac. Not too much to ask, right?
Well it turned out to be quite difficult and time consuming, with lots of wrong turns into blind alleys. So if you’re thinking about setting up something similar, here’s what worked for me.
This setup only really has two pieces:
A static blog generator—this takes files that you write (typically in Markdown) and converts them into a set of HTML pages, including a main page, individual post pages, archives, etc.
But first a little bit on how I arrived at this point.
Some Right Turns, Some Wrong Turns
There are many static blog generators out there. The most popular seems to be Jekyll, so I decided to have a go at installing that. It uses Ruby. Macs come with Ruby, so it should be easy. It went OK, but eventually I reached the point where I was required to upgrade Xcode. Xcode is a hefty download, and I didn’t want to wait, so I started looking at alternatives.
Pelican seems to offer similar functionality to Jekyll, but uses Python instead of Ruby. And Python is also pre-installed on OS X, so why not give it a shot? So I installed Pelican and the things that it requires: pip, virtualenv, and virtualenvwrapper. (Ignore the fact that the pip docs say you can get pip by installing virtualenv—the easiest way is to install pip and then use it to install virtualenv.) Pip also requires another package called distribute, so install that too. And if you want to write in Markdown, you’ll need to install the Markdown module, as described in the Pelican docs.
So now that I’ve got all these installed, it should “just work”, right? You wish. To get Pelican to generate the HTML, you need to run the make command with the makefile that comes with Pelican. But to get make (if you don’t already have it), you need to install the latest version of Xcode. (Déjà-vu much?)
So, much later that day, I have the latest Xcode, and have installed the optional (but required here) command-line tools. Now it works, right? Well, almost. Now I get an “unknown locale” error. Say what now? A little more Googling reveals that I need to set the LC_CTYPE environment variable in my .bashrc file to something like en_US.UTF-8. (An aside: I tried all this with tcsh, which I like more than bash, but ran into even more problems, so I switched back to bash.)
Anyway, now, finally, it works. On to the next piece of the puzzle—syncing the files to S3.
There were a couple of things that I tried that did not work for me. The first was trying to mount my S3 bucket as a remote drive using MacFusion. I thought I could mount the bucket right inside a folder in my Dropbox. But it didn’t really work.
The second was trying to upload using SFTP via an FTP-to-S3 gateway (like Cloud Gates). The gateway part works great (and I use it regularly for other stuff). And Pelican has an FTP make target that you can modify to use SFTP. But again, it didn’t really work.
s3cmd, on the other hand, works great. At least, once I figured out that I needed to install the latest version from Github instead of the one on the download page. s3cmd has a sync command that lets you sync a local directory with one in your S3 bucket.
Automating It All
The only thing left to do was to automate it so that as soon as I add or change a file in Pelican’s content directory, it will automatically regenerate the HTML and sync the output directory with S3.
On OS X, launchd is the thing to use. But manually creating the necessary plist files is a bit of a pain. Thankfully, there are tools that can make it easier. One of these is Lingon. I used it to add two items:
One to start Pelican’s make regenerate, which, once started, detects any changes in files in the content directory and updates the HTML
One to run s3cmd sync whenever the index.html file in the output directory changes
This is what they look like in Lingon:
I couldn’t get these to work by typing the commands directly into Lingon—I had to wrap each one in a shell script. This is what they look like. (Of course, you’ll have to change the directory paths and the S3 bucket name.)
To run make regenerate:
Don’t forget to chmod +x these so they can be executed.
Some Other Gotchas
When you’re writing posts, you must give them a title and a date, like this:
Title: My Awesome Post
If you don’t, Pelican won’t process them. You can also add a status of “draft”:
Pelican will put the generated draft post in a folder called drafts. The post will not appear on your blog until you remove this line.
This was a total pain in the ass to set up. But the result is so worth it. When I hit save in Textmate, and twenty or so seconds later, the post appears on my blog, it feels like magic. And because the files are in Dropbox, I can do the same in iA Writer on my iPhone or iPad (or move from one device to the other if the kids are playing Subway Surf on the iPad).
OK, well, not really. I’m actually splitting this blog up into two blogs. Stuff related to UX (and especially HTML prototyping) will be posted on the Livetyping blog, while everything else will be posted here.
Right now, the only thing on the Livetyping blog is my recent post about front-end frameworks, which I copied across from here. In the coming days, I’ll be copying other relevant posts over too, so they’re in the “right” place.
So if you follow me for the UX stuff, you should add this RSS feed to your feed reader.
But how can you know which one is best, without downloading them all and trying them for yourself? This post aims to save you the hassle by explaining the pros and cons of each from a UX prototyping perspective.
The two most popular frameworks are Bootstrap, originally created at Twitter, and Foundation, created by product design company ZURB. There is also a dark horse candidate called Skeleton, which was created by Twitter designer and former ZURBian Dave Gamache.
What Are These Things, Actually?
All three of these frameworks let you lay out web pages on a responsive grid. This means that you can make your design work well on any screen size. If that’s all you need, Skeleton fits the bill. (Bootstrap and Foundation also do this, but they bundle in a lot of extra stuff too.)
But for all but the simplest prototypes, you will almost certainly need more than just layout. The questions you need to be asking are What do we need? and What do we know?
If you need things like tabs, nicely-styled buttons and forms, standardized navigation components, consistent typography, and so on, then both Foundation and Bootstrap come with stuff that makes adding these things easy and fast (and they will look consistent too).
If you know how to do these things yourself (and want to), Skeleton could be the answer.
How they Look Out-of-the-Box
Skeleton on the Desktop
Skeleton on iPhone
Bootstrap on the Desktop
Bootstrap on iPhone
Foundation on the Desktop
Foundation on iPhone
What You Get in the Box
Skeleton gives you a responsive grid, some basic typography, and some simple form and button styling. That’s it.
Bootstrap and Foundation
In terms of feature lists, there is a lot of overlap between Foundation and Bootstrap. I won’t list them all out here because others have already done a better job than I would (scroll down to UI and Widgets at the bottom of the page).
In short, they both provide a responsive grid, nice typography, improved form styling, and pretty much any UI component that you might see in a modern webapp. So instead of listing them out here, I’m going to point out some of the differences between the two:
Bootstrap comes with a set of 140 (naturally) icons. Foundation does not include icons, but ZURB have created several icon fonts and a set of social icons (as separate products) that you can use.
Foundation has iOS-style switches, which are a nice alternative to checkboxes.
Both Bootstrap and Foundation have visibility classes, which let you show and hide elements depending on the screen size. Foundation goes one step further by adding visibility classes for device orientation and touch support.
This means you can do things like:
Replicate the pattern seen in many iPad apps, where a sidebar is displayed in landscape mode and hidden in portrait.
Show affordances on touch devices that usually only appear on hover.
Bootstrap seems to offer more built-in options for styling tables.
Bootstrap comes with animated transitions for fade in/out and slide in/out.
Both Foundation and Bootstrap have wizards that let you customize their framework before you download it. Bootstrap seems to have more things you can customize, which may or may not be a good thing.
Foundation has 13 templates for common page layouts that you can download from their site. Bootstrap comes with eight example pages included in the download.
But maybe the most important difference between the two frameworks is that Bootstrap is much more style-heavy than Foundation. This means that you see lots of sites that are very recognizably built using Bootstrap. For prototyping this may not matter so much. After all, what we are prototyping is not the visual design, it’s the layout and functionality. But on the other hand, if the way things look by default draws too much attention to itself, that may be a disadvantage.
As someone cleverly put it in an answer to a Quora question about this:
> It is like the difference between buying a custom Lego kit or buying a bunch of Legos on eBay and then trying to build something from the kits that you scrapped together.
Foundation and Bootstrap are both being actively developed, and new versions are released frequently. Skeleton, on the other hand, has not been updated in months. But since what it does is relatively simple, and because it is not engaged in a feature war with the other two (just the opposite, in fact), this may not matter in the slightest.
Now, you don’t want to be a sheep and just go with the one that everyone else is using. But popularity does matter. It matters because Bootstrap is attracting people to develop other products that are based on it. And some of those could be quite useful to us.
Protostrap lets you put prototypes together more quickly by using PHP to reuse content. It also includes some enhancements to Bootstrap, including a fake authentication layer, a way to handle missing pages gracefully, an iOS tab bar, a carousel with touch support, more icons, and more.
Jetstrap is webapp that lets you lay out Bootstrap pages visually, without having to write any code.
There does not seem to be anything similar for Foundation yet.
Under the Hood: Less and Sass
Both Foundation and Bootstrap let you work in plain ol’ CSS. But they both use a CSS preprocessor that lets you do more powerful things (and keep your code simpler). Bootstrap uses Less, while Foundation uses Sass. If you know what these are and have a preference, this may sway your decision.
Another important factor is how easy it is to learn each framework. For this, you’ll be relying on the provided documentation.
Skeleton’s documentation is understandably sparse. There’s not a lot to explain here, but the docs do a perfectly acceptable job of explaining it.
Foundation and Bootstrap both have very good documentation, but I think Bootstrap has a slight edge here.
Is any one of these head-and-shoulders above the others, a clear winner? No. All three frameworks are very competent.
So which one should you use? The answer is a typical, designerly “It depends”.
Each one just has a different emphasis, so which one is right for you depends on what you’re trying to do.
Do you mind all your prototypes having a similar look and feel? Maybe that’s even a positive in your eyes. If so, Bootstrap is a strong contender.
Do you prefer to impose your own look and feel on your prototypes (not necessarily a proper visual design that approximates a finished product, but maybe one that looks more wireframe-y)? Foundation could be the one for you.
"But which one do you use?” you ask. Well, I use Foundation. Why? Because I started using it before I’d even really heard about Bootstrap or Skeleton or had a chance to try them out.
And now I’m used to the way Foundation does things. I know how to do what I want in Foundation, so even if one of the other frameworks might be “better” for a particular project, I’m probably better off leveraging my existing experience with Foundation and bending it to fit the needs of the current project than to invest the time required to learn one of the others.
But if I was starting from scratch and trying to decide which one to use today, I’d probably discount Skeleton because Bootstrap and Foundation both provide so many useful extras. Using the provided components is much faster than reinventing the wheel and doing it yourself.
What it really comes down to is this: Can you live with Bootstrap’s style-heavy approach? And will the same framework be used in production? (This may not be your decision to make…) If so, then it’s more work (not for you, but still) to override Bootstrap’s styles to make it look the way you want.
As I’ve been putting together Livetyping (my HTML prototyping course), I’ve been thinking about situations when you shouldn’t prototype stuff (interface elements, interactions, whatever). This two-by-two chart sums up my thinking:
When something is hard to explain, but easy to code, you should code it. When the opposite it true, you should explain it instead (maybe using something like Polypage to add annotations directly to your prototype). These seem to be no-brainers.
But the interesting bits are the other two rectangles. If something is easy to explain and easy to code, what should you do? And what if it’s hard to explain and to code? Well, it depends. And the “it depends” is similar for both cases.
It depends on why you want to prototype this particular bit of the interface. Is it just to communicate how it works to developers and stakeholders? If so, explaining is probably the best route.
But if it’s so you can test your design with users, it may be worth putting in the extra effort to code it, especially if it is used in any important flows. Of course, if you’re in the hard/hard rectangle, you may have to collaborate with your developer colleagues to bring it to fruition. (Thinking about it, this flavor of “it depends” applies to all four scenarios—if it has to be in there for testing, then it has to be in there.)
There are other axes to take into account, of course, such as the relative importance of the thing you’re contemplating prototyping, and the novelty of the element/interaction, but I’ve found this to be a useful tool for thinking about this stuff.
If you’re still not convinced that prototyping is better than wireframing (even after reading this?!?), here are a couple of great articles that were published recently that you really must read.
In the first, Sergio Nouvel gives a good overview of the pros and cons of each of the different fidelity deliverables that we are used to producing. He then goes on to make a compelling argument for starting out with lo-fi mockups, then going straight to “wireframing in the browser”, which has a number of advantages:
With CSS frameworks, basic layout is a breeze.
Your deliverable is responsive-ready.
You can take advantage of what the browser does by nature.
It’s truly interactive.
The scalable nature of CSS enables easy, live changes.
You don’t need proprietary software or a powerhouse machine.
Everything you do saves you time later because you are building the real thing.
The second article, by LeisaReichelt, is a punchy, tour-de-force list of reasons why prototyping beats the pants off wireframing. It’s a really quick read—already condensed down to its essence—so I won’t ruin it by trying to summarize it here. Just take the two minutes and go read it over on The Pastry Box Project. It’s really good.
Happy reading :)
Recording the screen of a mobile device is not an easy thing. You can build a fancy test rig, with cameras and so on. But it’s expensive and cumbersome. There are iOS apps that let you record the screen. But the ones I’ve seen are either buggy as hell or require you to jailbreak your device.
But today I came across another option. AirPlay lets you mirror your iPhone or iPad’s display on an Apple TV. But you can also mirror it on a Mac, using a product called AirServer. The company that created it promotes it as a way to play multi-player games with your friends on a nice big screen.
But with your device’s screen mirrored on your Mac, you can use screen-recording software (like Screenflow, Camtasia, or Morae) to record it. Which, for user testing, is pretty damn handy. (The image above was captured from my Mac’s screen.)
(Disclaimer: If you use the above link to download and install AirServer, my free trial gets extended by three days. Just so you know.)
Learning HTML Prototyping—Where the Hell Do I Start?
OK, so you’ve read what various UX thought leaders have said or written about prototyping in HTML (or more generally about UXers being able to code) and you’re convinced that HTML prototyping is an important skill. Maybe you want to improve the collaboration between you (the designer) and your developer colleagues. Perhaps you want to improve communication with stakeholders. Or maybe you want to get your designs in front of your users earlier.
If you’re a freelancer, it could be that you are looking for ways to raise your hourly rate. Or maybe you’re an in-house designer who’s looking for a better job and who sees the value of having this important skill on your résumé.
But where do you start?
The following is my attempt to show you the alternatives that are out there. I hope it helps you find the way that best suits you.
Disclaimer: I have included Livetyping, which I created. Yes, I think it’s great. But I recognize that different people learn in different ways. If self-paced, screencast-based learning isn’t your bag, I’m sure you’ll find an alternative here.
There have been several HTML prototyping workshops run in various locations. A good example is UX Bootcamp’s Prototyping in Code, an intensive three-day workshop that has been run twice in London, UK.
It’s aimed specifically at UX designers.
It’s good for procrastinators and others who struggle with self-paced learning.
It’s a bit pricey (£299, which translates to $475).
It’s only any use if you live within a reasonable distance of the venue.
It’s not available right now. You’ll have to wait for the next one to be scheduled.
It’s hard to know which books to buy from the huge selection available.
None of them are really tailored for UX designers who want to learn how to prototype in HTML.
Not everybody likes learning from books or has the necessary self-discipline.
Online Video Courses
They are typically self-paced, which is great if that works for your learning style.
The cost is usually reasonable.
They aren’t tailored for UX designers.
You need to do your research to find the right courses.
You end up wasting time learning stuff that’s not really relevant for HTML prototyping.
Free Online Resources
Where do you go to find almost infinite resources about web technologies? The web, of course! Again, the quantity of information available is staggering. You can get all the information you need, but there are two problems: finding it, and being able to tell the good from the bad.
It’s tailored specifically for UX designers.
It’s great if you can’t dedicate a big block of time all at once.
You can work through it at your own speed.
Not good for procrastinators or those who struggle with self-paced learning (though it’s probably better than books in this respect).
HTML prototyping is a valuable skill that is in demand. There are many different ways to get this skill—some will suit your own personal learning style and how you value your time better than others. Best of luck!
While I was creating my Livetyping course, I realized that HTML5 might look a bit intimidating to some. It has over 120 different tags, which is a lot to get your head round. But in practice, when making interactive HTML prototypes, I only ever use a small subset of these.
So I made a cheatsheet containing just these commonly-used elements. Enjoy!
If you’ve got any suggestions for improving this cheat sheet, I’m @martinpolley on Twitter.
The course will be launching very soon. Sign up and I’ll let you know when it’s about to launch.
“It really troubles me when people use academic achievement as a means of measuring intelligence. You’re basically saying that somebody who is able to successfully jump through hoops and be submissive to authority is the height of intelligence, rather than looking at somebody’s capacity to think independently and creatively. I think that you can tell a lot more about somebody’s level of intelligence by sitting down with them and having a five minute conversation rather than looking at some letters on a piece of paper which, essentially, are meaningless.”
In April, Andrew Travers and Matthew Solle interviewed Cennydd Bowles for the London IA podcast. They asked him whether he is “a unicorn that codes” and whether he thinks that it is something that’s important. Here are the edited highlights of his reply. (In the original audio, this bit is from 17:44–20:18.)
There are two reasons, I think, why I think it’s useful to be able to code as a designer in our domain. The first is it gives you an understanding or an appreciation of what’s possible. And equally, what might be possible in six months’ time, or what might be possible if you’re able to kind of poke the developers hard enough and say “Go on—you can do it! Let’s find an innovative solution.”
The flipside of that is also that you know enough to call a developer’s bullshit. I love developers and I miss working with them as closely as I used to. But I think they would admit that occasionally they can be a bit obstructive, if they feel they’ve been left out of the loop or if they’re being forced to, you know, do something unreasonable in a silly timescale. And there can be sometimes a strain of the developer community that says “No—can’t do that. Nope, not possible. Have to go away and do it again.”
If you know your stuff, and you say “Well, actually, I’ve got a jQuery plugin here or something that can do that for you,” I’ve already saved you half the effort, then sometimes that can help realize your design—get past that kind of resistance.
The second reason why I think it’s desirable to be able to code is simply just because it helps the design process. Particularly for interaction design, I’m a big fan of trying to design within the medium. Now I don’t mean design in the browser—that’s maybe something we could talk about later—but I’m not a big fan of that, in terms of visual design and layout and so on. But I am a big fan of it in terms of the interaction design—how things respond to input.
And I think the sooner you can get that kind of design into its native state, be that on an iPhone, or on a telly, or in a web browser, then you can get a better understanding for whether it feels right, because so much of interaction design is about feel and rhythm and flow. The only way really to get that in front of people is to try and prototype it yourself. And I find HTML prototyping really adds something to what I can do. It helps me make the right design decisions, because I can get those interactions out, I can get them tested, and then I can iterate on those quickly.
The course will be launching very soon. Sign up and I’ll let you know when it’s about to launch.
Most of the work we do as UX designers is either for the web, or related to it in some way. The things that we design are often web sites or web applications. And even if they aren’t, web technologies are finding their way into more and more things: native iOS apps, Android apps, even desktop software.
And the web is a-changin’. Gone are the days when all you needed was a desktop web site or application with a fixed width of 960 pixels. These days, there is a vast range of different devices and screen sizes that you need to think about. And that range is only going to keep getting bigger.
If you’re still using static wireframes to design this stuff, you are doing yourself (not to mention your client, employer, and/or colleagues) a great disservice. Wireframes just aren’t up to the job of showing subtle interaction details—the things that make the difference between an application that is a delight to use and one that frustrates and annoys.
And even if you’re using a more sophisticated prototyping tool, you’re still not doing yourself any favors, because these tools don’t allow your designs to adapt to the multitude of different screen sizes that are out there.
37signals have been vocal proponents of this approach. In this post from back in 2008, Jason Fried explained why they don’t make mockups in Photoshop, instead preferring to “go right from a quick paper sketch to HTML/CSS.”
In an interview with Johnny Holland magazine in 2009, Todd Zaki Warfel, author of “Prototyping: A Practitioner’s Guide” gave some compelling arguments for prototyping.
I can also give our clients examples of how prototyping enabled us to uncover hidden problems, explore design solutions, and make informed decisions prior to launch that we simply couldn’t have done without prototyping…
Prototypes are about show and tell. They’re a visual way of communicating the design of a system. First and foremost, they communicate your design…
In nearly every case in the past three years, prototypes have become our documentation. … It still takes less time to build a prototype and write a 20 page supplemental spec than it would to write a 200 page spec and get consensus on it.
Any design based on a written spec is a design based on theory. A design based on a prototype is a design based on experience and practice.
I think another significant insight is that reactions we get to from our prototypes from clients and customers is far beyond anything we were ever able to achieve with wireframes and static Photoshop visual comps.
In 2010, Aza Raskin wrote a blog post that also touched on the subject.
To design is to inspire participation. To do that, you need to be respected. For that, you need to be a designer-coder.
In May of 2011, Jared Spool wrote the post that really opened up the can of worms.
Interestingly, it isn’t the designers who get to decide if coding is a valuable skill. It’s the hiring managers. And right now, based on today’s jobs market, it’s pretty clear where they stand. Many want to hire super designers—designers who can also code.
… those designers who have proven, practiced coding skills can demand a higher salary than those who don’t.
This provoked a flurry of responses. Matt Nish-Lapidus added to the career and team fit aspects that Jared covered:
I firmly believe that in order to do good design the designer must work with their materials. We can’t continue to just make pictures and flat representations of the things we’re designing. There is a time in the design process for making pictures, but it should be about generating ideas and refining them. There is no way to know what your web site, app, or other software, will actually be like without making a realistic version of a working interface.
Jenifer Tidwell agreed with most of Jared’s arguments, but cautioned that “organizations often value coding skills more than design skills. And when that happens, and you have two skillsets, which one do you think will get used more? Yeah.”
Nathan Curtis of EightShapes recorded a podcast with UIE around this time, and made a great point about the start-up cost of prototyping.
… once that start-up cost has been paid, whether it’s a day of prototyping or even a four hour chunk here, a six hour chunk there. Then things start to really move quickly. That’s in part because our ability to re-use and re-factor different things becomes a lot easier. As opposed to, “Well, you want to make the header twice as large.” In HTML we just change the height from 50 pixels to 100 pixels.
But in a wireframe, suddenly we’re caught going into 16 different files, having to move everything else on the page down, and all of those seemingly subtle changes end up costing a lot, too.
So for me, the ability to code is less about earning “cred” and communication, although I’m sure it has helped with both, and more about dependency and scope of influence. I am less dependent on the abilities and attention to detail of the developers, and I now have greater influence over the entire course of a project. As a result, the final product is better.
These posts also sparked interesting debates on the IxDA mailing list and on Quora. Despite a few dissenting voices, most seemed to agree that being able to code prototypes is a valuable skill for a UXer.
A number of workshops have been put together to teach UX designers how to code, but they’re only any good if you live close enough to the venue to attend. There are short webinars available that show you the why, but that aren’t long enough to go deep on the how.
The course will be launching very soon. Sign up and I’ll let you know when it’s about to launch.
The course is now available! Go check it out or sign up below for news about the course, HTML prototyping tips, and more.
So anyway, I haven’t done much on my webapp lately, but now I’ve decided to pull my finger out. I originally started playing around with Google AppEngine for the back-end, but I realized a couple of things.
First, I’m not going to get very far, nor learn very much, just by copying and tweaking Google’s example code.
Second, using AppEngine ties you in to Google. You can’t easily move elsewhere. So I figured I’d be better off not going that route.
So I’ve decided to take a step back and refresh my programming “skills”. On the recommendation of my friend Idan, I’m working my way through Learn Python the Hard Way. Which I’m rather enjoying. It’s not really a Python book. It’s more like an introductory programming book that happens to use Python.
I don’t have a clue about the back end. Not yet. How to set up a database, handle requests, query the database, write to it. But I’ll learn.
So what is this thing I want to build? It’s something that I want, for me. It’s like Instapaper or Read It Later, but for people who lack self-discipline. Those apps are great, but they have one limitation—they have no limits. I toss stuff into Instapaper willy-nilly, knowing deep down that I will never have time to read all of it (and maybe not any of it).
It has become a bottomless pit, sitting there, being intimidating. I now have Instapaper guilt. Guilt about all those important articles that I should have read but haven’t. It’s become like a second inbox.
My app will be different. If Instapaper and Read It Later are giant backpacks that always have space for more stuff, my app will be a carry-on bag. You can put a reasonable number of essentials in there, but when it’s full, it’s full. If you want to put something else in, you’ll have to take something else out. That way, you’ll have to be very judicious about what you put in there in the first place.
Maybe it sounds like a daft idea to you. Fine. No problem. But it doesn’t sound daft to me. And maybe there are other people out there who will find it useful.
My wife recently got a new phone. She said she didn’t really need an iPhone, so she went for an LG Cookie Plus. It’s a nice looking phone, with a decent-sized touch screen and quite a slim casing.
I played around with a bit and found it incredibly frustrating. The touch screen isn’t as responsive as the iPhone’s. Swiping is as likely to move something as it is to do what you actually want it to do. In lists, it is way too easy to select something when you want to scroll. Etc.
My wife said she wanted to send it back and go back to using her old Sony-Ericsson candybar phone.
But then a funny thing. She changed the wallpaper. She changed the background color from black to white. She changed the icon set from the default iPhone-like one to one that looked hand-drawn.
And suddenly the phone wasn’t so bad after all.
What happened here? A couple of things. First, she had made the phone her own. And maybe because of this, she was more willing to give it a chance.
Second (and I think, more importantly) the phone did not seem to take itself so seriously any more. Instead of being a vastly inferior iPhone wannabe, it was something else. It had stopped trying to be something it very obviously was not.
It was suddenly more honest. It’s just a shame that it wasnt like that from the start.
Michael Angeles has an interesting post over at konigi.com about how our tools are not important.
"Don’t let anyone tell you that the tools you choose are wrong or inappropriate. Find the right design and keep winning."
This got retweeted a lot. I read it and found myself agreeing. I even retweeted it myself. But since then I have been thinking about this a fair bit. And now I’m not so sure.
I think he’s missing something by only talking about one side of the tool question. The side that deals with working through a design. As he writes, “There are no good or bad tools for finding the right design.” But there is another side to this. And that is concerned with what we do with the things we create using our tools.
And there I think there are not insignificant differences in fit between the actual deliverable and the thing we want it to do for us. As Bill Buxton has said on many occasions “Everything is best for something and worst for something else.” And we use the deliverables that we create for several different things: To show to our designer colleagues for the purposes of collaboration and critique. To show to stakeholders, for the purpose of getting buy-in. To share with our developer colleagues so that they will know what to build at the required level of detail.
A wireframe is good for working with design colleagues. A video walkthrough may be the best thing to show to stakeholders. And a high-fidelity HTML prototype may be better for communicating to developers than an annotated wireframe.
Maybe I’m stating the obvious here. What do you think?
I just listened to an old episode of The Conversation, where Dan is talking to Garrett Dimon, Cameron Moll, and Faruk Ates about how you know when an application or design is done.
Garrett Dimon said something that particularly stuck with me. He talked about the importance of having a vision for what the thing is going to be like two years from now. You use this to help decide what new features to add to your product, but perhaps more importantly, what not to add.
This ties in with something that Jared Spool has mentioned on many occasions—one important characteristic of successful teams is a vision of what the experience of using the product will be like five years from now.
One of the dubious benefits of having a leased car is getting to drive a different car whenever it has to go to the garage for something. (This time, a cracked windshield.) The one car I actually enjoyed was a Prius. All the others were meh, including the Toyota Corolla that I have at the moment.
One of the more annoying things about this car is the gearbox. Automatic transmission has been around for many years. The interface is pretty much standard by now, and car manufacturers need a pretty good reason to mess with it. One such reason was the addition of tiptronic gear changing (which the Corolla also has). So why has Toyota gone and changed the interface from the usual Park/Reverse/Neutral/Drive/1/2/3 pattern?
For starters, Park seems to have been removed. And “E” seems to have replaced Drive. (Any idea what “E” stands for? Me neither.) Reverse and Neutral are still there. And M with plus and minus is pretty standard for tiptronic shifting. The numbered gears have gone. No need for them when you have got tiptronic shifting. (And this transmission has five gears, so this is a good solution.)
But the most mysterious thing is the big button marked “M-MT Es”. Pressing it does not have any obvious effect. Nothing lights up. The behavior of the transmission seems unchanged. In fact, it is impossible to tell if it is on or off. For all I know, it may have more than two states. (The label seems to suggest that this is the case.)
If you know the answer to this mystery, please tweet or mail me. I am genuinely curious about this. (One possible explanation that I can think of is that maybe here in Israel we get cars with localized labeling for some non-English-speaking European country…)