Semester In Innovation

This summer I applied and got into a course called Designing SFU Mobile, or Semester in Innovation. The goal was to take students from computing science, business, and interactive arts and technology (IAT or SIAT), and have us work together to develop and design a product to drive SFU’s future mobile direction. The instructors wanted to have the course be mostly student driven with minimal instructor intervention.

The first two weeks of the course were very structured and we met on campus every day. The instructors organized team building exercises such as tower building and scavenger hunts. We were also asked questions like what we thought “mobile” means and asked to do presentations on the spot in front of the class. I thought this was a very good experience for many people. One guest speaker gave us tips on how to put together good business presentation. He had us do an exercise where you get up in front of the class and do a presentation on the spot based on 5 random slides. The slides only had pictures, no words, and range from things such as birds and snowflakes, to cross sections of cabbage that looked like a human brain. I think of myself as a fairly competent speaker, but I found this to be very challenging and learned a lot from it.

Tower build by myself and three other students. I think our tri-force design should have gotten us the win Smilie: :P

After the first two weeks, we split up into our separate disciplines for some different tasks. The business and IAT students conducted user surveys and workshops to try and figure out what students needed to improve their experience at SFU. Myself along with the computing science students were told come up with some cool proof of concept in two weeks. Two ideas were pitched and we organized ourselves into teams based on which project we wanted to work on. I worked with 4 other students to develop a mobile application that would show your location on campus only using wifi. I could go into great detail about this project, but I don’t want to. Instead I will write another post about our two week spike and post a link to it when I’m finished. I will say that I was pretty happy with what we managed to come up with in two weeks. We ended up with a fairly functional application for Android and Blackberry devices.

In the two weeks that we were coding, the business and IAT students came up with final project proposals and pitched them to the class. We (the computing side) were somewhat dejected at first because most of the ideas sounded the same. The student surveys showed that SFU students wanted some sort of “all-in-one” (this word was thrown around a lot in the pitches) application that would consolidate all resources for the students different courses. The ideas sounded like glorified dashboards, which from a computing standpoint isn’t very innovative and development would not be mentally stimulating.

After the first round of pitches, the course instructors challenged us to think how any of these applications would help improve mobile learning. This seemed to spark a change in the next round of ideas. We ended up with 5 or 6 products, which we narrowed down to three. I will create a page with more details on these projects when I have some time.

The first application was called Real Questions Real Answers (RQRA). It’s a smart query engine that is tailored to SFU. The vision was for students to be able to ask questions like “What is professor James Smith’s e-mail address?” or “What time is my MATH 152 midterm?” and get accurate answers.

Main screen of Real Questions Real Answers (RQRA)

The second application selected was called SFU Engage. Engage allows students to share learning resources for each of their courses by submitting a url. The application parses the content and display it to the user. Through the student surveys and workshops, it was discovered that students prefer learning from peers. Engage aims to take peer leaning online and make it social with the use of comments and likes.

Screenshot of the completed Engage application

Lastly, there was the application initially called “Tag Tool” (later changed to Accent). It is a web application that enhances online and distance education by allowing users to watch lectures online and tag certain parts of the video (simliar to soundcloud). A user can tag a section of a video and describe what it is about, or tag a specific point in the video and ask a question which can be answered by the instructor or classmates. This tagging allows users to review video or audio lectures much more efficiently since they don’t have to seek through a long video to find content they desire.

Video viewing / tagging screen from Accent

Now that we had finally settled on our three projects we started organizing ourselves into teams to develop the three applications. The CS students decided that we would be best off letting our team members focus on what they know best and work across all three projects where they are needed. This was contrary to the business and IAT teams which were split into three teams, one for each application.

Next we decided to define our technology stack. Each of the applications was going to be a web based. The reason being that a properly developed web application is viewable on any device with a browser which makes it extremely accessible. We decided to develop the applications using Node.js, mySQL, elasticsearch, and redis.

Over the next few weeks, we familiarized ourselves with the tools we would work with while the IAT students were to come up with the user stories for each application. If there was one point in the semester I could go back and change to improve our final product, it would be here. The computing side foolishly left the IAT students to come up with user stories and requirements for the application at their leisure. Most IAT students have never developed software so they don’t know what sort of user stories are needed in order to develop an application. One of our team members did try to have meetings with them every few days, but he was meeting with all three teams, all while trying to learn Node.js. Rather than overloading one team member, we should have assigned three people to act as Business Analysts (BA) for each project. It took far too long to get the system requirements and in the end, we received too few user stories to be useful which left a lot of the implementation up to the developers. I believe that assigning one BA to each team would have drastically sped up the requirement gathering process and would have yielded quality user stories that we could immediately use as developers.

User stories for Accent project in Pivotal Tracker

During the requirements gathering phase, our computing cohort realized that it was taking too long. Anticipating the worst, we decided to look at each application and find core objects that could be shared across all three applications. A system data model was created, and we went to work developing the models for our application. This was another thing I would have changed about our development process. Initially our team wanted to try to practice iterative development, but coding the entire back end first caused us to fall into a waterfall development model. With our time constraints I don’t think we really had a way around it at that point. We knew our time was limited, so we had to start developing something. The models were the only thing that we could be confident writing at that stage without proper user stories. I think this would have been avoided had we assigned BAs and driven out requirements more quickly.

Final data model drawn up using Lucid Chart

Eventually we started getting mock ups from the designers which provided more detail to the user stories. This is when our development really sped up. We decided to write a REST API which each application would make use of. The API would allow us to develop native mobile applications in the future if we chose to. A couple team members shifted gears and started converting the UI mock ups into HTML/CSS. Another member created a bunch of AJAX methods that our front end could use to access data returned from our REST layer. Everything started coming together quickly.

One thing I learned working with designers is that they may not realize how much their designs influence the functionality of the software behind it. Many times, we were presented with new screens that have new text fields which imply changes to core data models, or new screens all together.

While all this was going on, the bussiness students were getting worked very hard by their instructor to come up with the final Business plan for each project. It was 80 pages of financials and a bunch of other businessy stuff that I don’t yet understand.

Two of our three projects were fairly well polished by the end of the semester. The third, now called “Accent” instead of “Tag Tool”, was still very buggy since we started development on it last. I’m not very proud of the applications themselves. I’m more proud of how well our computing team organized ourselves and adapted. Only half of us had done coop terms before, and I’m guessing fewer had worked directly with designers or business people. One thing I took out of this course is how valuable working with designers can be. Although our final applications might not function perfectly, they look damn good and having something that looks polished helps tremendously when pitching an idea to someone.

The course didn’t go exactly how I expected it, but it is the first time the course has been offered, so that’s ok. Having students from different faculties work together in this fashion is a great idea and every student will take away some invaluable information that no other faculty specific course can offer. I think we will see the quality of talent coming out of SFU would greatly improve if these types of courses are offered more often, and earlier in students education.

Category(s): School

2 Responses to Semester In Innovation

  1. no way! our tower was much better!

  2. Hey Mike

    I am pretty interested in these apps. Stuff we talked about at UBC all the time. Are they available on github to download and develop further?


Leave a Reply to Cat Cancel reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>