In my previous blog entry I had decided that I wanted to produce an interactive lab script that would be able to adapt to a user on the fly. I briefly discussed the merits of such a design, in my situation it helps every student taking my session to have an optimal introduction to swift regardless of their experience. I also talked last time about my little theory that the music tech students will probably be able to visualize concepts such as program flow better than we might expect (due to the transferable skills acquired from operating analogue mixing consoles). The app will begin by asking the user a series of questions, it will use this information to make a bunch of assumptions about the experience and ability of the user and then present them with a lab script suited to their needs.
A rough flow diagram showing how the app can make assumptions about a user based on the questions they are asked in the beginning.
Pictured above is a very simplified version of how I will prescribe the lab scripts to different users. Firstly the app will need to know the undergraduate background of the user so it know which direction to gear the lab script. At this point I reach my first point where I have to make a generalization, to make the most informed generalization possible I will have to use existing literature. Unfortunately there is not a huge amount of collective data on the programming capabilities of mus tech students, this is where the results of my survey come in. In an earlier entry I talked about conducting a survey of my classmates who have experience with learning swift to develop audio apps. From the analysis of these results (which I will be covering in depth in a few weeks) I will be able to make assertions about users based on measured evidence, not just my own thoughts (no matter how close I might be to the answer).
The second question I will be asking users is where they have programming experience. This section could get fairly in depth, I could probe people on what languages they have used and get a really clear picture of their background. As I said, I could do this however I don’t need too. Instead I will be using a little slider that asks something along the lines of “rate your programming experience 1-10, 1 being non 10 being bill gates”. This way I can easily ascertain the experience of thee user. I am currently undecided on whether I want to add any extra questions on launch. I have thought about including an option that asks whether you want the script to be visual or plain text and whether you want to focus on programming in swift or making sounds. All of these options would need to be added early into the development process due to the significance they play in the design of the app.
Now let’s get to how you would go about implementing such a system. Firstly the results of the calibration survey get stored into memory as numbers (0,1 for background and 1-10 for programming), these values are saved for the session (unless they are changed during the script). The app would have the same structure for any combination of numbers but the content on each screen would be different depending on the stored data. For example on a page talking about controlling labels with UI objects a user no programming experience (0-3) would be walked through a basic task (for instance adding a UI button and making it control a label). A more advanced user would be told quickly how to implement the same thing, but then be shown more advanced controls such as colour and opacity control. There can be different points in the app where the different ability groups have completely different screens and points where they are essentially on the same screen. Hopefully this should reduce the potential errors likely to be present in a complicated app.
Pictured above is a prototype diagram of how the app will function. The real app (obviously) will have a lot more screens and a much more complicated flow chart explaining the relationships between the views. The app functions as a dynamic experience for the user but the bare bones will be strictly linear. An issue with making the app have a different view for every parameter would be making sure that all the views work in conjunction with each other. In the past I have experienced problems moving between multiple views within swift, causing all sorts of nasty errors. The last thing I want to be doing is bug fixing my program for weeks on end!
So hopefully I have outlined the ways in which the app will function and the reasoning behind my design choices. I plan to include plenty of pictures and visuals and depending on survey feedback will be adding the plaintext/visuals option to the core design of the app. The flexibility of swift as a platform will allow me to create a very flashy and fancy app that will actually be able to deliver a good experience to the end user. The goal of my project has essentially turned into designing a lab script that will optimize the lesson time for an AMT (audio mus tech) student from any academic background!
My surveys are almost ready to go live and I will be writing about the feedback in a few weeks. In my last entry I talked about the merits of interactive lab scripts, you can find that entry here.