ETEC 511 – Project Retrospective

I feel that this was an interesting project to be a part of, and coming into it late, eliminated some of my ability to influence the direction of the group, but I think my role became an early critic – asking pointed questions so that I could understand why decision were made – and help support them. One of the things I often did in meetings was try to help tie our decisions back to course readings, course content, and thinking about the project less as a project and more as an assignment. I think I also served as a bit of a wrangler of ideas, trying to limit scope creep.

One other thing I did was in my section (accessibility legislation) really try to refine the information into questions and answers, so that particular section became conversational. I recall talking about making our language plain, simple and understandable and how we could use that as an engagement strategy, and in turn making it more usable, which was I think my most important contribution to the process. I will admit my passenger-ness to the project, and did not feel 100% like it was my project (again, coming in late to it made it a bit of a challenge) so I always saw my role as a bit of a servant to the whole.

From a Nielsen (2003) perspective, Twine was at the same time easy to use and learn the basics of quickly. The simplicity of the design of the tool (questions and answers with expositional text) were easy to construct in Twine. The complexity of the subject matter however, made Twine a difficult choice to manage how each component piece linked. Had we not limited our choices to discuss, we absolutely would have been tangled in a web of, well, Twine. I think that the affordances of Twine’s output, especially in the way we designed the tool, kept the complexity down, which in turn allowed the tool to ultimately be more usable.

I don’t know if Twine ended up being the best choice as we had to bend it quite a lot to make it do what we wanted it to do. The tool ultimately configured us as designers, as we were pretty locked into Twine. While it ended up perfectly fine, it did limit us in some ways, that due to our technical understanding of what was possible and the time constraints it would have taken to further use Twine beyond what it is built for, I wonder if this would have been simpler to build using HTML and delivered a more accessible tool in the end?

References

Nielsen, J. (2003). Usability 101: Introduction to usability. Useit.