...
We should have worked out our paper prototypes more before starting our computer prototype. we had to do a lot of expensive changing because we hadn't really settled on a design. The paper prototype session was very helpful, and after it we decided to completely change th strucutre of Coshare by using alums instead of tags. With such a big change, doing another paper prototype iteration ourselves would most likely have been very helpful.
We should have focused on the front-end more during the computer prototype iteration, and not even started on the backend. We started the backend in parallel with the front-end in GR4, but spending time in the backend resulted in less time for the front-end. The user heuristic evaluations were all centered around the front-end layout with no expectation of a working backend; reefining our front-end approach would have led to a more complete prototype that could be intricately critiqued instead of critiques about more fundamental problems that just weren’t implemented.
We should have had all members of our team become more familiar with interacting with the backend, instead of relying on one person for it. Teaching the team about Django basics would have allowed more efficient solving of front-end/back-end interaction bugs that slowed down development.
We also should have relied on libraries like boostrap more from the beginning rather than tried to design a look and feel ourselves.
A major thing was starting out as a completely site that would never reload and execute all operations with Javascript and Ajax. However, in some cases it was a better design to use page redirects sometimes instead of AJAX. Considering this choice more before implementation would have saved us trouble, as we had implemented a lot of Javascript functionality that in some cases was no longer even used with page redirects and reloads.
We should have researched more from the start how to deal with content effectively. We didn’t realize that rendering large amounts of content could be problematic. However, our site had issues we had with memory usage of images. This affected usability as users couldn’t upload many full sized images without slowing down page renders. Also an issue with displaying videos was a function of intrastructure limitations- <video> elements are not very reliable. Testing earlier the assumption that these would work smoothly would have led us to better planning around this obstacle.
All of these problems however, are great learning points for future projects. Having studied and gone through this comprehensive design process, we now have a better idea of how to get worthwhile prototypes to users at low cost, and iterate more effectively on the design. We also have much more defined ways to analyze UI design, which leads to better communication and easier logical decisions as a team.