UX and Design
Usability testing is a powerful research method that assesses people's actual behavior, not just their self-reported actions. Well-designed usability tests can help researchers understand the effectiveness of a product, but poorly designed tests can yield unhelpful or even misguided insights.
Before putting any sort of test in front of users, it is important to know what you as a researcher want to know about your product. That way you can design a test that will provide the type of insights that you need.
Last week one of my colleagues challenged our UX team at Viget to put ourselves in our users’ shoes by taking a usability test. I went ahead and took 30 tests, all on the rapid-fire testing site UsabilityHub.com. My takeaways from that 30-minute session are as follows:
In an effort to better present and document my code, I decided to go through what I’ve written thus far with a fine-tooth comb. Fortunately, AngularJS (and consequently Ionic) is an MVC-based framework, meaning that code is logically divided between the model (the data and inner workings of the program), the view (what the user sees), and the controller (which controls the view based on the model).
For example, let's say the model is an array of 10 numbers, which exists somewhere in the code. The user may only see numbers one and two. The controller controls what the user sees, setting the array to only display numbers one and two.
I firmly believe that clear code reflects a clear mind.
Messy code is at best unpleasant and at worst near impossible to read. If you are working with friends or coworkers, you will drive them up the wall with unorganized code.
Last weekend, I spent more than 10 hours trying to figure out why my custom highlighting functionality was not working in iOS Simulator, yet worked perfectly in the browser. I did not find too many resources online, so I am writing this post in the hope that it may shed some light for others.
Until this point, I had written a series of functions that split one long string (a paragraph) into an array of strings (individual words), separated by whitespace. I recorded the first and last strings touched by a user, and applied a yellow background—a "highlight"—to the first string, last string, and all of the strings in between. The touch event fired continuously, and so as a user dragged his finger across the screen, the last string he touched updated continuously.
Coding is the new literacy. It's easy. Everyone's learning it. Everyone should learn it.
We've heard those refrains before. The truth is, programming is difficult.
Not the act of it itself, at least for quick and dirty front-end effects. In fact, I found programming to be quite logical and straightforward. What made me want to pull my hair out was everything before and after writing code—like how to set up my environment, where to start a project, and which tools, languages, and frameworks I should devote my time to learning. I spent—and still spend—hours trying to figure out how to do simple stuff. Many other beginners feel similarly.
In my last post, I mentioned that I’m starting this blog in part because existing online materials cater to either total beginners or accomplished programmers. Here are four reasons why learning to code is difficult—and none of them involve the actual act of writing.
So, what have you been up to?
I get this question a lot. Here's the short answer—last summer, I left my wonderful job as a real-estate reporter in New York City and moved to Dublin for graduate school.
The more interesting question is why.