Superficial Intelligence

Yesterday, my User Interface Design class team finally presented our final implementation of our quiz-making interface. Although there were many parts left unimplemented, I feel satisfied with our work. The following picture is my team with our poster (I'm the one on the left):

And this is a screenshot of the interface. More specifically, the image library and the quiz builder:

I am amazed with how much I have learned in this class, especially with this project. The whole process was very rewarding, even if tiring at times. Some of the things I learned were:

1. Ideas don't tend to translate into code in exactly the same way as in your mind - The end result of this project was quite different than my first idea. Although the basic idea remained the same, many aspects of it changed during our design and implementation process. Just communicating the idea with my partners was enough for them to interpret the details differently and form their own design opinions. This was clearly evident when our team divided into two subgroups and made two entirely different paper prototypes. Another reason for this idea evolution is users. We had to design with our users in mind and that meant sometimes adding new features and removing others. Finally, implementation complexity played a big role in our design decisions. We had only one semester for this project. Therefore, we had to focus on the parts that were really important and eliminate many nice features for which we simply didn't have the time to implement.

2. Paper prototypes are cool - Our first design was a low fidelity prototype on paper. This was a very interesting experience. The reason for this approach was to allow a larger number of design ideas to be tried out and to avoid unneeded implementation and emotional attachments that come as a result of spending too much time on a design. This way, discarding designs and exploring more ideas became much more simple. Also, when we moved to the actual coding part of the project, we were able to focus more on the functional part of the code, since the design was already specified. The paper prototype served as a great guideline for adding all the different components to the project.

3. Evaluations and user testing are important - If it were up to me, I would've started coding directly from our paper prototype. Yet, there were still a lot of obvious (and not-so-obvious) problems that had to be addressed. To find these problems, we did everything from cognitive walk-throughs to heuristic evaluations. Then we took our first implementation and did user testing. We found lots of problems. I am amazed at how many. Buttons were missing, tasks were tedious, and things we thought were obvious confused our users. Thanks to all the testing we did, we were able to address most of these problems.

4. Rash implementation decisions can lead to coding frustrations - One decision that we made before starting to code led to a lot of troublesome problems later on. Initially, we wanted to store quiz information in a database. Due to timing constraints and the fact that we were using an entirely new programming language, we decided to use simple, temporary XML files to store our quiz data. XML files were very easy to use and handle using this programming language. The problem was that we left the files organized as if they were the actual database, which separated quiz information from questions and question groups. With a database, this would be easy to manage, but with XML files, keeping track of all the dependencies became a pain. If only we had just stored each quiz in a separate XML file...

5. I love procrastination nights - We had one night were, after pretending to code for a little while, we decided to just go play video games. It was my favorite project meeting. And, I believe it helped us work on our teamwork too. Every now and then, it is good to just take some time off and procrastinate.

In conclusion, I think what I learned during this project was: ideas change (especially when mixed with other people), paper is still cool (especially for "interface scrapbooking"), evaluations and testing remind you that your designs are not perfect (who would've thought the program needed to be usable too), hasty decisions produce frustrated programmers (I'm still dreading those XML files), and procrastination is good (well, only sometimes...).