I have spent all my (little) free time this past month revising the text for the Fnk thesis. Because, while the draft was successfully delivered last semester, we now have to write a new one based on changes suggested by teachers and, of course, adding the conclusion to the project. As a result, I spend those few free hours planning on what new content to add to it and what to expand. There’s still a lot left to be written – I’ll be doing so this semester – but the blueprint for the changes is set, at least.

The biggest change I’ve done to my project both on paper and in practice is related to usability testing. While this is something I had already planned (in a way), it wasn’t fully described on my thesis draft, and it was something mentioned during my final review by the college teachers as being one of the biggest holes on my proposal. Due to this, I’m spending some good time writing usability test guides, tasks and outlining its objectives that I’ll be using later this year.

Truth be told, this has been pretty enlightening. Not because it’s something I’ve never seen before: I’ve done formal usability tests in the past, as part of my academic course. But, with normal website interface development, my approach with usability and testing has, sadly, been the same as many other people in the field: work with intuition as you build, then do a few tests at the end of the development, internally and informally, and only change showstopping problems. Of course, nobody thinks this is ideal, but the truth is, it usually works when the client wants to see the website go live yesterday, so it’s the widely accepted norm when you’re not building something heavily based on usability guidelines, like a portal.

With Fnk, I’m doing things a bit more formally – academic style, but with a bit more openness to make use of the Internet – hence why thinking seriously about the task and writing actual test guides has been so interesting. As such, there will be two kinds of usability tests: a few closely directed tests, and public tests.

The first will be a number of tests I’ll conduct with test candidates – selected friends and colleagues who are willing to lend me a few hours of their time – with specific goals in mind and with full result reporting, as well as taping of the user experience process. User tasks will be guided and the goals will be pre-determined, all tied to the current development progress. This is actually what’s forcing me to have a very strictly outlined development schedule (which has also been rewritten); since I will be conducting those tests once a month, it’s important each of the tests are focused on new features and interface elements, or else sequential tests would lose their reason to be.

The public tests, on the other hand, will be a long round of public alpha-testing that will be ran by anyone willing to spend a few minutes trying Fnk. And since Fnk will be easily available on the website, this means anyone, really. People who do so will have the ability to send feedback on the software operation and interface, but I’m still outlining the details of how this will happen. This will be a lot more loosely guided than the other test, though, and there will be constant updates so this is not so much schedule-based.

While this change towards a more formal user experience-focused development (relying on test scenarios instead of intuition only) will cover the biggest sore point in my project, there’s also other thing that popped up during the review of my thesis: what was the reason for selecting the technology I’ve chosen (Flash)?

This is an interesting point because of two things. First, when doing work for college until today, I usually tried to avoid working with Flash as much as I could – the way I see it, there’s no point in doing something with a technology I already know, as the learning process wouldn’t be as effective as it could. That’s the reason why I’ve chosen to work with Max/MSP, Processing and vvvv during some work that didn’t require me to do so, while colleagues picked Flash instead. There’s actually very few works I’ve done using Flash for college, and all of them were selected due to reasons beyond my personal control (either because the course required it, or because the rest of my group wanted to use it).

Enter Fnk, and it’s a bit ironic that my last work done for college is finally based on Flash by my own choice; while I have looked into alternatives like Java (and even C# when I contemplated a different target), I decided on Flash specially because of the ubiquity of the player and the features I knew would be present in Flash Player 10. However, I figured that once I knew it was the best platform for the task, it wasn’t worth going to deep in explaining my reasoning; it just felt the obvious choice. This proved to be a problem during my review, and this brings me to my second point: because some teachers know I work with Flash, they tend to think I’d selected Flash solely because it was easier for me, not because I actually believe it’s the best choice for the specific task at hand. This was also pointed during my review, and that’s when I realized my defense of Flash on paper was too weak – barely mentioning the flash player penetration statistics, and also failing to mention the negative implications of this requirement.

The result of this all is that another new chapter of my thesis will be solely dedicated to explaining the selection of Flash as my platform of choice for this job, specially comparing it to alternatives such as using Java, JavaScript, and others. Should be an interesting read.

As a final note, it’s interesting that, when confronting the work you have planned – and which you’re sure will work – with the critical opinion of others, they’ll always find some important holes where you see none, even if they’re not so into the technology you’ll be working with, or if they don’t fully understand all parts of the project. My teachers might not be so Flash-savvy as I am, but they’re still intelligent people and had a bunch of valid points. This kind of confrontation is also interesting because it may help you understand your actual thought process – things you don’t even care a lot about might be the first thing some other teacher will mention, and it’s easy to misunderstand their point.

Anyway, before my final review last semester, I had the belief my project was pretty solid. I still think it is, but after those two points get explained in longer detail, I have no doubt it’ll be a full step ahead in terms of quality of the written content.