My first week with Ember.js
Ember.js did prove frustrating at first with the official docs being really sparse and the rapid development of the framework meant assorted tutorials floating around the net are mainly outdated. For example, Ember.js uses convention-over-configuration, but the docs for what those conventions actually are were for some reason removed after the 1.12 release. Thankfully Rock and Roll with Ember.js was recently updated to Ember 2.0, so I picked up the eBook and my beginner experience was back in happy land.
I spent yesterday working on the sign-up page for Passport Date. This will be a two (or three?) page series of forms for creating a new user account. I started by making each page a separate Template. Which meant separate Controllers and Routes, and then the framework was slapping my hand when I tried to do a Model.create() and have a model instance float around in limbo between these pages. Perhaps there is a simple way to do this, but it seems against the grain of the framework from my beginner eyes. So then I tried a model store and find but now it seemed like I had to save and load information from the server between pages, which was equally wrong. So I went to bed a little frustrated and thought I was trying to follow the framework too closely and why don’t I just put the whole form on one page and use the simple CSS display property to hide and show each page?
Which is what I did, but it got me thinking about how working in frameworks it often feels like there is a strong impetus to build functionality in a certain way. Especially if there are prominent cookbooks, example apps or blog posts that use specific design choices. It’s just easier not to go against the grain.
It’s a lot less true these days, as the different communities of the web have cross pollinated with each other a great deal, but it used to be easy to tell if a web application was built with PHP, Java or Python just by how the user interface was laid out. Each programming community tended to riff HTML, CSS and UI elements from each other.
Application Development influencing User Experiences: online dating
In online dating applications, this user interface and user experience really guides how the user will interact with that application. For example, eHarmony lets you send out a “wink” first, then move onto trading a multiple choice set of questions between two potential romantic mates before finally putting a blank message window in front of them, all while doling out only a limited number of matches per day (this is from an older iteration of eHarmony, I believe today they follow a more traditional online dating user experience model). This tells the person using the app that online dating should first be interacted with online. User’s typically spend at least a week cautiously pinging and poking before getting to the point where they exchange numbers and discuss a real life meet-up. On the other side of the coin is Tinder, where users swipe and people appear under a mutual match tab and the bio is just one or two sentences and first interactions tend to be along the lines of, “Hi, how’s it going? Want to meet?”.
In either case, one could message right out of the gate on eHarmony asking to meet or one could send a person a series of multiple choice question and answers on Tinder, but the interaction would feel like the person isn’t playing along with how the application is meant to be used. And ultimately it would result in a lot fewer real life meet-ups.
Another example is Plenty of Fish. It looks and feels like an ASP application. While it’s entirely possible for Plenty of Fish to have a design team create a modern UI experience and have the developers implement that in their existing ASP stack, they haven’t done so to date. And this crude user interface gives Plenty of Fish a reputation for attracting a more, um, lower class set of users. PoF is notorious for users with profiles with horrible grammar and messages consisting of “sup?” and “hey!”.
On the other side of that spectrum is OKCupid. It’s developed in C++ of all things, but it feels like a PHP or Rails app. These are frameworks that draw people interested in creating a focused and designed user experience first and foremost and the development stack is just a pragmatic tool to enable that. OKCupid is intended to be a smart dating application. It boasts a fancy matching algorithm and encourages users to fill out questions and answers to improve match percentage quality before messaging each other. In addition, it doesn’t just provide one or two text fields to fill out, but a whole series of them, encouraging users to write long essays. This user experience draws in more educated people who believe starting their search for love begins with a precise set of information. Initial messages are more often several sentences or even paragraphs in length on this platform.
The way users interact based on the application design bleeds into the real world. Tinder users who meet often have the expectation that sex may happen with the first or second date. eHarmony users who meet may more often expect a series of candlelight dinners and walks on the beach before giving it up in the bedroom. OKCupid is an environment where witicisms and interestingness are currencies of quality, and the path to love has a tendency to be put further in the backseat. Two people who meet on that site may both find each other interesting for a long term partnership, but they may both feel more pressured to play up their more wity and conversational selves first out of fear that their mate in pursuit be distracted by other users on the site who present those aspects better. And a person who browses Facebook and messages single woman on the site is considered a creepy cyberstalker, while on Russian Facebook (VK) there are fields suitable for advertising oneself as single and what you’re looking for in a mate.
Technology enables new personal interactions in real life and each specific implementation influences those initial interactions and expectations. Modern love affairs in some small part are guided by the software upon which they first use to meet each other.