Honours Project

Personal Honours Project - Critical Reflection

If you had asked me at the start of the year what I’d be thinking about submitting as my final submission for my Honours project, I would never have expected it to be a mobile app on how to teach beginners how to code. Especially considering my starting point was looking at communities and given that a number of times through out the year, I felt my research didn't fit with what I would go on to create in the end. In hindsight however, everything was relevant and without it, I wouldn't have gotten to my final iteration; it just wasn't the output I was expecting to create.

I think that’s one of the main things I’ve learnt during this year; don’t go into things complete dead set on an idea or doing things a specific way and that the best results can happen naturally. Overall, I’m proud with what I’ve created and I’ve definitely flagged up an area of interest I would like to continue exploring in the future.

I think this year I’ve really tested my limits as a designer and I’ve certainly pushed myself much more in comparison to other years. I think working on a project I am passionate about has been a huge factor in keeping me dedicated to working hard and because of this commitment to work, I feel proud to stand by my project knowing I’ve worked hard and to the best of my ability. In tangent to this, I’ve learnt how to organise myself - physically and mentally - to make sure I can deal with the stress and pressure of this year, while still managing to stay on top of everything.

Given more time I would loved to have explored the possibilities of using two devices for the learning experience. Originally I’d had an idea about creating applications for a tablet and another on a mobile device with the former acting as the output and latter as the editor. As the project progressed my interests lay more in working with smartphones and so the idea was scrapped but I think this would be an interesting area to explore, especially when introducing beginners to coding languages.

This project has definitely helped me find the areas of design I want to get involved with - specifically user experience design and designing digital products. The latter is something I’ve known for years but this project has reinforced that desire to work in this area. This year has allowed me to further develop my graphic design skills but it has also highlighted that my interests lie less in user interface design, which I thought they did at the beginning of this project, and that I was much happier using my graphic design skills to create strong user experiences. I think this project will allow me to show that I have what it takes to work successfully in these fields.

However I do partially regret staying in my comfort zone this year and not taking the opportunity to take the plunge and work physically or do something completely different than working on applications. Creating my Mk. 1 project, as basic as it was, piqued my interest in working physically and I think this is something I would certainly like to explore more in the future. This is why next year I’ve seriously considered undertaking my Masters in Product Design to begin exploring these areas of interest properly.

I do feel like I underestimated the technology aspect of this project. Ironic given the topic of my project but I would have liked to have experimented more with coding languages during my time studying as my coding skills are not as strong as I would have liked at the end of my four years studying. However, I understand that I am not a developer and I am more interested in design than technology. This is why I opted to create my prototypes with Proto.IO and given the steep learning curve of this software, I feel like I have produced a convincing, high quality prototype.

Finally, I would have also loved to explore the possibilities of working with Arduinos and Raspberry Pi’s to create more solutions which blend the physical and digital and this is something I hope to say. Mastering these skills I feel would make me an overall more multidisciplinary designer. 

Personal Honours Project - One Hundred Words

When writing my 100 words, I had a number of things I wanted to get across about my project:

  • What is it?
  • Where it came from?
  • How does it do it?

With 100 words being quite to do all this, I knew I had to be concise and straight to the point when crafting my statement. In the end, I was happy with the words I created to summarise my project.

100 words:

Codable is a smartphone focused learning experience that aims to make the process of learning code less daunting for beginners. It stems from an interest into how adult informal learning could be encouraged on mobile devices and how elements of constructionism learning could turn these devices into proficient learning tools for topics such as coding languages.

Codable allows learners to take charge of their learning by allowing them to tackle and learn code at their own pace. Rather than interacting directly with code, users complete tasks using multiple choice options; taking a pseudocode approach to learning code as opposed to traditional hands on approaches.

Personal Honours Project - One Great Image

To compliment my video, I knew I would need a strong image to reinforce the idea of using the learning experience in places where learning does not traditionally occur. I knew that for a better image I would need someone actually using the app in one of these settings.

Ultimately I decided to use this image of the user using the experience at home as it provided a nice natural setting for the type of image I wanted. 

While experimenting with photography however, I did take some great shots (that would become detail images) that focused more on the app itself and were more focused on capturing the detail in the screen states. They were shot with the books I’d use during the project as backgrounds. These images were good for including in the process booklet at the end of the project. 

Personal Honours Project - One Minute Video

Satisfied with my app for hand in, I decided to focus my attention on the rest of the hand ins we would need - in particular my one minute video. Videos are something I'm not overly comfortable doing so this is why I decided to tackle this first so that it was done and out of the way.

In terms of what I wanted to show with my video, I felt the most important thing to show was to get across the idea that the learning experience could be accessed in a variety of places and that learning could occur at any time. When storyboarding, I also considered which features of the experience would be the most important to show. Looking through everything, I narrowed it down to:

  • Showing the learning goal screens when you first access the experience
  • The introduction to the exercise screen
  • The exercise overview screen
  • Task 1
  • "That's not right" screen
  • "That's right" screen
  • "Congratulations" screen

Showing these meant that I managed to show the various aspects of the experience that the learner would be come across while showing passage of time by showing these different screens in different locations.

Once everything was planned I began filming. The first scenes were shot in my flat's kitchen as I wanted the video to show the app in the most natural settings as possible and in less traditional places than where you would assume learning would take place i.e. avoiding libraries and other places of learning. The only exception to this rule was that one scene was filmed in the studio which acted as the place of work. 

Showing the user using the device in the car...

In a cafe...

Even at night...

Overall I actually really enjoyed shooting my video for this project and hope that it compliments the rest of the deliverables i.e. the 100 words and the great images. My video can be accessed here.

Personal Honours Project - Mk. 2 - Acting on Feedback & User Testing

Preparing for the Mk. 2 presentation certainly paid off, as the overall reception to my project was positive. The feedback I received from Chris, Andrea and Nick Taylor (who was sitting in on our presentations) was that I need to prepare my users for what to do next after they complete their current learning goal as well as help them define what their ultimate goal is from using the experience. Andrea also pointed out that I had neglected to show a self-assessment screen which is a huge part of constructionism learning. Nick also suggested I include some way of actually applying the knowledge learnt at the end of the experience, perhaps in some sort of assessment.

Moving on to what would be essentially Mk 2.1, I began by tweaking everything - various screen states were added, removed and modified to make the prototype feel less static and more like a native iPhone app. This was important to work on so that while the learner is working through the experience their immersion would not be broken by the prototype stuttering or not working as expected.

One of two new screens I added in particular was a new welcome screen that welcomes the learner back and asks if they would like to continue their learning. It also highlights the learner’s current goal which in this case will be to complete “Finish Introducing JavaScript”. To do this, the app will tell the learner that they will have one more exercise to complete and will provide a direct link to the start of the Let’s Code: Rock, Paper, Scissors exercise to encourage people to pick up where they left off.

The other screen was a self assessment section that users are required to complete when they finish the whole exercise. During this section, the user gets a recap of everything they came across during the tasks and they can tap to select anything that they felt they struggled with during the tasks. After swiping through everything encountered during the tasks, they are taken to a summary screen that highlights what the users felt comfortable using and also highlights what the learner struggled with during the tasks. Anything that the users had problems with can be assigned as their next learning goal i.e. the learner struggled with variables through out the tasks and if the user presses the provided button to do so, their new learning goal can be set too “Mastering Variables”.

For the prototype the learning goal title is pre-defined but given more time I think it would be important to explore the possibility of allowing the user to name their own goal to take ownership other learning.

With these screens, I felt I had successfully acted on the critique received during the presentations. 

Satisfied with my prototype, I felt it was time to begin user testing to get feedback from users. As I'd done for Mk. 1, I prepared a list of questions that I was looking to answer from testing but I was also interested in just listening to how the user perceived the app and what their experience had been like with it without prompting.

Tester 1 found the app to be clear, easy and had a range of options for help that they appreciated, being a beginner to coding. They also praised the use of wording as it was friendly and easy to follow; they also commented on the fact that it was encouraging, which was reassuring to hear that they were on the right track. Tester 1 also liked that you could view the code after each task, as this helped them visualise how the pieces of code would fit together in the program, as well as helped them think through it. 

When asked what the app did particularly well, Tester 1 said that the ending was well executed as it gave you nice summaries of everything encountered during the tasks and highlighted where you could find each of them again in the tasks. This helped them reinforce their knowledge. Their only critiques were that while the prototype had a menu overlay it was not functional and would have liked to have access to the options and that the help button may be a little lost in the screens.

Tester 2 had similar thoughts on the experience - they liked that you could see the journey along the bottom and you could visually see how far your had to left to go to complete the exercise. They also loved that you could play Rock, Paper, Scissors at the end as you then got to see firsthand the results of you working through the various exercises. They also commented that the code view was welcomed as it also helped them think through the tasks and was interesting to look at.

Their critiques were that I should extend the hotspots on the overview to include the symbols at the end, as the tester mistook them for buttons. They also suggested that I include an introduction to how the app works, perhaps before task 1.

Personal Honours Project - Mk. 2 Presentations

Mk. 2 was essentially to show off the progress made between Mk. 1 and Mk. 2. Needless to say I had a lot to fit in within 5 minutes. This time I made sure to make a presentation and a script to follow, after being so unprepared for Mk. 1. This definitely helped me in the long run.

To begin with, I made sure to let Chris and Andrea know that the focus of my project had shifted slightly - I was now focusing on creating smartphone focused learning experiences. I was still drawing ideas from constructionism learning and encouraging adult informal learning amongst adults but with less focus on communities of practise. I'm also bringing in my interest of redefining the boundaries of what smartphones could do.

I began the presentation recapping about what I'd done between Mk. 1 and Mk. 2, and especially what I'd taken away from Mk. 1. My main problem I found was that I was having trouble communicating what I was trying to do. I thought it was best to try and communicate my idea physically, as people respond to something they could physically interact with.

Once I recapped everyone on what I'd done after Mk. 1, I showed how I'd taken the physical experience digitally and then ran people through my Mk. 2 prototype. You can read my walkthrough of my prototype in the script below.

Some of the feedback I received from the presentation was that I need to put more emphasis in introducing self-assessment learning to the app as well as preparing the user for where to go next and how they will achieve their ultimate goal. I also need to pay more attention to the animations and prepare my prototype for a second round of user testing.

Presentation

Script

Personal Honours Project - Mk. 2 Prototype

Mk. 2 was the first on screen iteration of the project. After my discussion with Chris about focusing on a UX project as opposed to a UI project, this played a big part in what wireframes I’d created earlier made the final cut for the prototype. A lot of the wireframes showing how the users could select and find topics to study were dropped in order to make a more streamlined prototype.

The prototype from Mk. 1 became the main focus of the Mk. 2 - the scenario being that the user has spent several months with the app and is ready to move onto the final exercise of a course called “Introduction to JavaScript”. To complete this course users will create Rock, Paper, Scissors to test themselves on several features of JavaScript.

Introduction Screen

The first screen of the experience and it makes sure to give the learner an overview of what they’ll be doing at this exercise. The “What you’ll use” bar shows the symbol pattern I designed and used that shows which aspects of JavaScript the user will use through out the experience - every time the aspect is mentioned through out the experience, the corresponding symbol is featured somewhere to build familiarity in a visual way. The bar can be swiped to give a short description about each aspect of JavaScript and the corresponding symbol.

The use of symbols was used in place of colours to build familiarity and distinguish between different aspects of JavaScript as to worked better with the branding of the app without the need to include any extra colours. They are also inspired by graphic organisers used in self-assessment learning. 

The introduction screen also gives small additional information about the difficulty level for the learner and a rough estimate of the time scale it would take to complete the task if they tried to do it in one sitting.

Using the instructions button takes the user to more detailed instructions to use the experience but this was more put in place for showing the experience at the degree show than for seasoned users of the experience.

Overview

Moving on, the user can see that exercise is split into 6 major tasks (or steps) and 12 tasks overall to complete the exercise. Each major task gives a brief description about what the learner will be expected to do at each task. The symbols at the side of each task give the learner some indication of what they’ll be working with at each task. At the bottom of the overview, the user can choose to begin the task or see the code that they’ll working through the exercise to create.

Exercise Screen

In keeping with the Mk. 1 prototype, to complete the task users use multiple choice to choose the best course of action to complete the requirements of the task. Each task clearly states what the learner is doing at each task with additional information to give the user some more context. The options are in the centre of the experience and there’s an indicator to show that the user can swipe between the 3 options to determine the best course of action to complete the task.

When the user has selected the desired course of action, they can use the button to check their answer. This will tell the user whether they have gotten the answer right or wrong and some justification for their answer if right, and a hint if they are wrong.

Also present is the symbols established earlier in the experience that corresponds to the chosen choice of action - if users can’t remember what a variable does they can hopefully recognise the symbol associated with it.

Finally learners can track their progress at the bottom of the experience - as the user works through the tasks the hubs link up to visualise the user’s journey through the experience. This was a way of incorporating the circles and path metaphor I was trying to create as the experience;

Overall I think it works much better as a visualisation of the user’s progress rather than an experience itself. When the learners swipe the task bar, they can see an alternative progress bar that fills up as the learners progress and shows how many tasks (out of 12) the user has completed and a percentage of completion. This is to get additional information on how the learners are doing if they require it or don’t understand the visualisation of the user journey.

Help Options

There are 3 help options available to the users if they require help. These 3 options were added based on the persona’s user needs as well as feedback I received from Mk. 1 testing - a hint, asking other users for help and accessing a reference list.

Hint - gives a hint on how to complete the current task and varies in helpfulness; at the beginning of the tasks the hints eliminate options but as the user progresses through the tasks, the hints give a slight nudge to the correct course of action but ultimately leaves the user to work out the correct course of action for themselves. This method of help was created with bright beginners in mind who were possible doubting themselves about the correct course and just need that little reassurance they’re on the right track.

Peer Support - allows the user to see who else is on the exercise with you and who can help you with any questions you might have. The learner can type in their query to the chat box and post it for the other learners to see. The other learners in the module can then respond to the question with help. This method of help was created with both bright beginners and anxious amateurs in mind - both would be benefit from that reassurance of speaking to your peers and it also ties in the research insights gained from researching communities of practise. By allowing users to chat to each other, they can specify the level of help that each individual learner may feel they need.

Exercise - Help - Social.png

References - allows the user to access a list of references that will give the user a reminder of what everything does in JavaScript. Here users can see remind themselves by seeing the associated symbol, looking at a short description of what aspects of JavaScript do as well as gives the user an example of how the code would look. The reference list will only show the user the aspects of JavaScript that are relevant to the exercise as to avoid confusing the user with too many unnecessary terms. This method of help was something requested by users during testing of Mk. 1 and could be both be used by anxious amateurs and bright beginners.

Each help method is provided to try and build reassurance and confidence with the learner. They were designed to have varying degrees of usefulness based on the type of help the learner feels they need.

Task 3 and 5

Tasks 3 and 5 differentiate slightly from the other tasks because they are split into multiple tasks. When the user begins the task they are given more information about what they will doing and the specifics of the task. These screens are designed to break up the repetitiveness of the experience and also an opportunity to encourage the user and build their confidence by being reassuring. They are also natural stopping points for the learner so they can feel like they’re in a better position to leave the experience before returning to the experience later. When the user is ready to continue the experience they can click the button below and be returned to the multiple choice tasks.

Task 6

Task 6 also differentiates from the experience in the sense that it does give you a multiple choice option to complete the task. Instead the learner is expected to apply the knowledge they have learnt through out the experience and technically write their only piece of code. The task provides a text box to input their answer with a hint above the text box that shows the user how to word their code. Task 6 is in important because again it breaks the repetitiveness of the experience and also provides a good learning opportunity for the user as well as an opportunity for them to apply and reinforce their knowledge. When the user correctly inputs in the code, the exercise is considered finished.

Rock, Paper, Scissors Screen

The end of the experience, it was important to properly congratulate the user and further build their confidence by using extremely positive language and using language that praises the user for creating the program on their own merit. Since an important part of programming is actually using the program you’ve spent time coding it was important to include an opportunity at the end of the experience to actually play Rock, Paper, Scissors with your phone. 

Personal Honours Project - Branding

After a week of deliberating what the app should look like and trying to draw inspirations from websites such as Behance and Dribble, I decided I had to start making something and began applying styles to the wireframes I had created.

 

Visual Language

When creating the brand, I was trying to draw inspirations from several sources. One of the major influences was the design language of iOS 9 as I knew this was the platform my app would be shown on. As such, I wanted my own app to look as native as possible on the device but still have it’s own unique visual language. After not really finding anything that I was in love with, I decided to try the branding I had established through out the year for documentation, presentations and my Mk. 1 prototype. Ultimately this worked out extremely well and I succeeded in creating an app that looked iOS native but had it’s own unique brand.

 

Colour Palette

What I found when working with the blues I had used was if correctly and in varying shades, it created a visually strong and appealing app. Breaking up the blues with white created a nice contrast and tied the app together. This palette I feel works well and is clear and legible for users.

 

Typography

For typography I used two variations of Proxima Nova (Bold and Regular). Bold would be applied to headings and parts of the UI that needed to stand out to the user. Regular would be used as body text. Despite being the same font, the two weights compliment each other well and meant that I did not require a second font to compliment Proxima Nova.

typography.jpg

 

Tone of Voice

When considering my tone of voice, I was keeping my user at the forefront of my mind. To avoid the beginners feeling out of their depths, the app would need to be friendly, encouraging and easy to follow. Reassuring the beginner and building their confidence were my two of my goals that I’d hope to achieve with my experience. This is a reason why I think the blue works well for the experience - blue is a calming colour that is not as provocative in comparison to other colours I could have used.

 

Naming and Logos

When thinking of names for the app, Codable fit as a name that I felt summarised everything that my project was attempting to do - enabling adults to learn coding languages.

After deciding on the name, I sketched out various logos, focusing mainly on typography logos. In the end I opted for a logo that used Proxima Nova to fit with the typography of the app. I then drew a circle round the word to tie in with the other design language in the app. 

 

Final Brand

Personal Honours Project - Wireframes

With an idea of I was going to tackle the main experience and with it planned out, I referred back to my wireframes I had created when I was experimenting with the blocks and circles and path experience.

Originally I had created wireframes for a full application but on reflection, and to make the overall experience I was trying to convey with my prototype concise, I only took forward a small number of the wireframes I had created. 

In addition to this, I had to create several new wireframes to plan the experience and that acted upon the suggestions from user testing during Mk. 1 as well as the needs from my personas, bright beginners and anxious amateurs. 

Wireframes were mostly kept on paper with some moving forward onto POP (Prototyping on Paper) to give me an idea on how to create a fluid user journey for the experience before moving onto Proto.IO to begin building the prototype.

Personal Honours Project - UX vs UI

Translating the physical Mk.1 prototype experience digitally was the next major challenge for my project. After successfully testing and refining the experience based on the previous suggestions, I went back to paper to sketch the new experience. 

To start with, I realised that the path system I had use for the physical prototype would not translate properly digitally without looking extremely complicated and intimidating - something I was looking to avoid when introducing beginners to coding. 

I began sketching ideas for alternatives to the paths but still tried to work them in, in some form. This included looking at things like turning wheels to select options and swiping blocks to fit it into the circles to choose actions. I looked at incorporating colour to the wheel to create familiarity between the different aspects of JavaScript (orange for functions, green for arrays etc), and how the wheel could possibly change colour when the user chooses an action. However I was finding myself getting frustrated with trying to make this work on a small screen of a phone.

I spoke with Chris through the week who gave me some good food for thought concerning my project. He asked me what I would like to do after uni and I replied that I had an interest in UX and UI. After this, he asked me whether the focus of my project was more UX or UI focussed - if it was UI focussed then I would need to take more risks and explore the wheel approach and make it work for the phones. If however it was more UI focussed then I could afford to be more conservative with my decisions to make the experience better for the user.

Ultimately I felt that this project was more suited as a UX project, especially since I was dealing with something as daunting as code for beginners - creating a complicated UI would not benefit beginners and so it was time to consider more "conservative" options.

Replacing the progress bar with the path system seemed like the best solution for incorporating it somewhere in the design and is a nice alternative to a standard progress bar. Dropping the circles and instead using plain text for explaining the tasks at each hub meant that I can still achieve a strong UI without overcomplicating it for the user. I also decided to keep the 3 options for choosing what action to complete the task and this seemed to go down well in the physical prototype. It was just a case now between choosing a slide to choose interaction or have a grid where the user can see the 4 options. 

Personal Honours Project - Moving forward

After writing up the responses I received from the testers, I did a quick brainstorm about how I could solve the various recommendations and problems that arose through testing.

Problem - Difficult and confusing for learners

Solution - Create a gentler learning curve for beginners. With multiple testers making comments concerning the difficulty I knew I would have to change the way I used written language through out the experience and making sure that the learner had multiple options for points of reference and support through out the experience. Another possible solution was to create an introduction to the experience that serves two purposes: to teach the learner code but also to serve as a way of introducing the learner to how the experience works.

Suggestion - more colours, less text heavy

Solution - Use colours associated with a text editor to create familiarity. With the full intent of eventually moving the learner on from the experience to be working in text editors, creating this familiarity early would be important for making users feel confident they make the move. To give myself colours to work with, I used the text editor Sublime Text as an inspiration.

Suggestion - Add definitions to hints

Solution - Add an "In case you've forgotten..." button/tab/feature to the hints. This would allow users to gain more information if they are unsatisfied with the level of help they are receiving from hints or need more of a nudge in the right direction. Alternatively a reference button could be added to the list of available help options that learners would direct access to the reference list instead of them requesting a hint each time they need to access to the list.

Suggestion - Add code to an off screen editor as you complete the experience.

Solution - As users select code options, move it to an off screen editor to see how the code all fits together at the end. While users are not directly working with code through out the experience, it's important to build their confidence when they will eventually deal with code on text editors.

Suggestion - Give the user justification for why the action they choose is the best course of action.

Solution - After the user has selected their answer, a notification window could appear to explain to the user at the end of each task why the action is chosen is the best choice. The help features could also be expanded with an emphasis on making the help features more social. Through this method, users could create learning opportunities for themselves by sharing knowledge over the platform and also tie in the social aspect of learning from research.

Suggestion - More emphasis on showing the code on flip. More prominent tooltip?

Solution - When desired course of action is chosen, the bubble should auto flip to show you the code. This should be partnered up with the justification of the best course to reinforce learning. The more confidence built during the experiencer, the easier the transition will be for users to move on to working with actual code. 

Suggestion - The means to toggle on or off help as dictated by the user

Solution - Creating a Guided version vs Unguided version or incorporating a help button somewhere on the screen for the user to access when or if they need to access the help options. Depending on the user's confidence level, the user could make use of a guided version which would work to build the user's confidence by encouraging the learner at every opportunity and making sure to explain everything that the learner is coming across during the experience. When users are feeling more confident they can choose the unguided mode which would allow them to opt out of hints. Either way, the key is to build the learner's confidence.

Suggestion - Make sure to consider the order of learning - when should learners be introduced to this topic.

Solution - Following examples set by established websites such as w3schools or Codecademy. This again is another reason why linear learning journeys are more suited as learning experiences as learners shouldn't really be learning anything that should make them feel out of their depths.

Personal Honours Project - Mk. 1 Prototypes - Make or break(!)

To test the experience, I enlisted 8 people with various degrees of familiarity with the coding language JavaScript - this ranged from complete beginners to more experienced users. I asked participants to read the instruction sheet I had provided for them and then took a back seat to observe the participant, takes notes and run the experience i.e. making the bubbles appear at each choice for the user to pick from. If the testers were really struggling, I acted as the help feature too in a social sense - if the user got stuck they could reach out to their peers for assistance via communication channels via the app.

Some of the testers were shown the raw code for the program we were creating to give the tester an idea of what we would be creating.

Tester 1 - didn't show code before beginning, familiar with JavaScript

Tester 1 found the experience confusing to begin with and commented that she felt the experience would be too difficult for beginners. However, they liked that the experience made them revisit knowledge established earlier in the experience, and the final question of the experience created a good learning opportunity. The tester also liked that the code was actually teaching you to do something.

Things to consider - difficulty level, using more colour and less text.

 

Tester 2 - showed code before beginning, some experience with JavaScript

Tester 2 said they found some sentences hard to understand and was having difficulty remembering what the different things did in JavaScript. They suggested incorporating a dictionary or some sort of points of reference for the users to have while learning. Tester 2 also suggested that at the end of each task at the hubs, the app should tell you why that's the best course of action - this will create more learning opportunities and build the confidence of the learner. Overall, they enjoyed the experience but found it difficult; they agreed though that it successfully broken down code structure to make it more manageable.

Things to consider - creating a reference sheet or dictionary, explaining answers to learners, categorising different aspects of JavaScript by what they do - using colour again to create patterns(?). More emphasis on encouraging users to tap and flip the bubbles to see the code.

Tester 3 - showed code before beginning, no experience with JavaScript

Tester 3 really struggled with the task but this was unsurprising considering the first two participants had commented on difficulty and the tester had no experience with JavaScript. She relied on the help feature a lot (i.e. me). She completed the task but said she did enjoy the experience. However she did find it slightly overwhelming to begin with.

Things to consider - creating a reference sheet, especially for beginners that clearly explains what everything does, an introduction to the experience and the way of teaching.

 

Tester 4 - didn't show the code before beginning, no experience with JavaScript

Tester 4 found that the hints were very helpful in narrowing down the answer, and again commented that the experience should do more to encourage users to tap the bubbles to view the code. They suggested that when you select the right bubble it should show you the code so that you still view it in some way. The tester enjoyed the experience and definitely felt like they had learnt something during the experience.

Things to consider - make the tap to see code more prominent, show the code when you select the right action, add definitions of JavaScript to the hints.

Tester 5 - showed code before beginning, no experience with JavaScript

Tester 5 enjoyed the experience overall but did find it challenging to begin with. They did comment that it made sense by the time they reached the bottom of the experience and that the things like the hints made everything easier to understand.

"Code is too daunting."

They ultimately felt like they learnt something and they liked working on their own through out the tasks to make use of their problem solving skills.

Things to consider - adding code to an off screen editor as you go that can be accessed at anytime/at the end of the experience to see how the code all fits together, questions with logic operators could be clearer and an option to toggle the help features on and off in an effort to build user's confidence.

 

Tester 6 - showed code, some experience with JavaScript

Tester 6 liked the pseudocode approach of breaking down the code and said that this worked well. They enjoyed the experience overall and managed to complete the task with minor difficulty. Their only problem with the experience was that they felt some users might constantly swipe away hints and tips if the users are receiving them every few minutes.

Things to consider - hints only if prompted or wrong action chosen too many times, user might get bored with constant reasons why x does y.

Tester 7 - didn't show the code before beginning, experienced coder

Tester 7 was the most experienced coder out of the group and completed the task relatively easily. However they did comment that some questions needed to be clearer. They did praise the pseudocode approach and said that the experience successfully broke down the coding structure. Tester 7 did comment that I need to make more emphasis on explaining every aspect of the experience, especially the differences between pre-defined functions (Math.random()) and user generation functions (compare()). Tester 7 also made sure that I had considered the order of learning - should this topic be introduced before this and so on.

Things to consider - wording of questions, making sure to talk through everything with the learners and consider the order of learning

 

Tester 8 - didn't show the code before beginning, limited skill

Tester 8 was the last person I tested the experience on. Tester 8 said that he needed something like this for learning coding initially - something that makes it more manageable to digest.

Things to consider - draw more attention to the names of variables and functions established through out the process so that you can refer back to them, just need to be more consistent with sentences. 

Overall, this was very worthwhile and gave me lots of things to consider for my experience.

Personal Honours Project - Mk. 1 Prototypes - Experience Prototyping #2

With the board ready to go, it was time to bring in the content for the experience. Thanks to the planning, I knew what I needed in terms of paper work for the experience. The hardest part was trying to word everything to make it clear and simple for beginners to understand. This was something though that I wouldn't be able to know if I had been successful at until testing so I did the best I could before hand.

For each 'hub' as I was calling them, I created a task, 9 hints and 3 possible answers for each task I was asking the learner to complete at each hub. On the back of each answer was the code associated with the possible action; I did this for learners who felt like they might learn better by actually seeing the code. The hints varied depending on the task - some would make the answer very obvious for the learner and some would only subtly point in the correct direction. Multiple choice made the overall task easier but still kept some sort of challenge element for new learners to code.

With everything prepared, it was time to bring the board to users to begin testing. I was very apprehensive about testing as I knew that if this experience prototype still didn't convey my idea then I would definitely have to go back to the drawing board, which would further eat into my time.

Personal Honours Project - Mk. 1 Prototypes - Experience Prototyping #1

After what I could only describe as a disaster of a presentation, I went back to my desk to lick my wounds. Chris and Andrea didn't seem very enthused with my idea of using circles and paths to break down code structure; I felt like I was on to something and wanted to continue pursuing it. I just needed to rethink my approach on how I was going to do it.

I spoke to Chris the following day who came to check how I was after the presentation - I told him I was planning to continue with the circles idea but I admitted that I hadn't presented well at all the day before, which Chris agreed with. Even with all of my sketches on the wall, Chris was still struggling to follow what exactly I meant - my main problem was that I was not conveying what exactly the experience would be. 

Rather than stress about how I would do this digitally, I took the plunge and decided to work physically. I knew I was on to something and I was gonna prove it works by any means necessary. As it happened though, creating this experience prototype physically was the most fun I've had with my project all semester.

First step was to plan how I was going to do this physically. Luckily, I'd been sitting with a wooden board since the end of 3rd year from a previous project so I quickly identified this as my new "phone screen".  I then sketched up a rough plan of what I wanted and I would need to make it work. Nails, string and paper - lo-fi materials and working as far away from technology as possible. 

To tackle my main problem, I knew I would have to start utilising actual content. The only thing was that the lightbulb example I had become hung up on using wasn't actually a very good example for teaching JavaScript - or rather, it wasn't varied enough for beginners to learn different parts of  the language. Taking inspiration from Codecademy, I made sure that I would be teaching my users something fun they could do with coding, and that's why I selected programming the user's phone to play rock, paper, scissors with them within the app as an easy introduction to what we can do with JavaScript. The next step was breaking this down for users to understand.

From this...

From this...

...to this.

...to this.

Breaking it down meant writing out my own code for the program, and then breaking it into 6 more manageable chunks. In unavoidable cases, I split some sections into sub sections but I didn't actually mind doing this as I think it created a bit more variety in the path structure I was aiming for, while making the structure more visually appealing. Once I'd broken down the code into steps, I then created a mock up path and what the user would be expected to do at each 'hub'.

With the steps mapped out, it was time to create the physical prototype. As I mentioned, the board from last year's project was to become my "phone screen" and I mapped out roughly how I think the path should look for this program - there was no real plan other than trying to make it look visually interesting to users. I used a roll of masking tape to measure the circles and map out the connections to each circles, before hammering in nails on the edge of each circle and cutting bits of strings to create the paths. This process was oddly therapeutic.

Personal Honours Project - Mk. 1 Prototypes - Prep

With Mk. 1 prototypes due on the 22nd of February, it was time to begin turning my thoughts into an actual app to present on the day. Moving the giant sheet off my desk and onto a nearby wall for reference, I began sketching out the different screen states.

Back in December in my Honours Concept presentation I had already outlined my prototyping process so I knew roughly what I should be doing and when I should be doing it.

My process was:

  • Paper prototyping
  • Basic coding prototyping
  • Edge prototyping

A critique that I'd had from my last project working with apps was that I didn't show enough of my sketch and paper work, so I made that a priority this time when prototyping. That was part of the reason I spent a whole week brainstorming and visualising my thoughts on paper - not only was it helpful but it also helped visualise my process. While I sketched out all of my screen states, I put particular emphasis on sketching out the learning experience - if I didn't get the experience right now, the rest of my project would suffer later.

DSC_0628.JPG

After brainstorming a number of "coding metaphors" (or ways coding could be interpreted by someone e.g. knitting, doing a jigsaw puzzle) I'd narrowed it down to two that I felt could be an interesting way of teaching coding.

Primarily inspired by the physical programming kit LittleBits, the first experience involved using a building block approach where users would place pre-generated pieces of code represented as blocks together to create their programs and teach them about topics such as functions. For example, the app would ask the learner to arrange the blocks correctly to switch on a light. If the user got it right, the light would switch on. Behind the scenes, the blocks would do things such as initialise variables and create the if statement to make the metaphorical light switch on. 

After drawing up the screen states, I moved them onto the prototyping tool Prototyping on Paper which takes pictures of your various screen states and allows you to create prototypes of apps by just using hotspots to link the pages, and gives the prototype basic functionality. This platform was useful for showing people my idea quickly and talking them through the experience.

After exploring the experience on paper, I moved onto a quick lo-fi Adobe Edge prototype to quickly mock up how the interaction would look live. While there is little room to add complete functionality on Edge without incorporating JavaScript libraries, I made do with creating a linear animation that followed the timeline; after all this prototype was just to give Chris and Andrea an idea of how the interactions would look.

On the run up to the Mk. 1 however, I became less enamoured with blocks as I was finding that during market research this was the approach others had taken using varying degrees of simplicity - some gave more details about code, some didn't. I had a small brainstorming session where I looked again at coding metaphors. One metaphor I'd overlooked was a connect the dots - if the dots are not connected in a specific order, the picture it makes is not correct. I thought this could be easily adapted to coding - if the code is incorrect or in the wrong order, the program will usually not run. 

Looking back at my research as well, I'd become quite fascinated by the ideas of circles and paths. Once I realised this, it felt like a bit of no brainer to then explore this metaphor, as I'd been drawing it for months before. I took the lightbulb example again and redrew the editor screen - rather than having a bar where the blocks would sit, I created an outline of the lightbulb using circles. The idea would be that the user would tap the circle they were trying to fill and would be presented with 4 options for each circle. When the user has chosen an option, a line would be created to the next circle and so on until the circle is complete. If the code is correct, the light would switch on.

As I'd done for the block experience, I put the circle experience in the POP app and created another lo-fi Adobe Edge prototype that showed how the options would appear when the circle is pressed. I took this experience one step forward and created a quick Photoshop image of how it may look. Wary that I should be preparing users for moving onto text editors eventually, I took inspiration from text editors such as Sublime Text and the website Codecademy.

I also moved this image into the prototyping software Framer Studio. Framer Studio allows you to upload static Photoshop files into the software and apply code (a version of JavaScript called CoffeeScript) to the different elements to create animations. However the learning curve on Framer is steep and I'm not if it's a tool I want to use to create my final prototypes. Yet if I was successful in learning how to use the tool, I feel this would give me a great prototype to show for Mk. 2.

Personal Honours Project - Thought Gathering

All of this week, I've spent time brainstorming ideas about my application. I've tried to keep loose during this time and follow every train of thought as they happened. At the end of the week, I assembled all of the 8 A4 pages together to create a map that explored various aspects of my project.

Some of the things I considered during the week what my inspirations were for my app, how some of the screens may look and what interactions would be implemented, how the branding may look, the "happy path" of a one of my personas as well as creating questions to ask myself based on design tips from InVision (part 1, part 2). Overall it was a successful week that helped me put my thoughts into perspective and visualised what I would need to consider when creating my screen states next week. 

DSC_0580.JPG

Considering Avatar branding.

Looking at the differences between non-linear and linear user journeys. While sketching these out I realised that my different personas would have different requirements. A free fledgling would opt for a non-linear user journey where as bright beginners and anxious amateurs would lean towards having a linear user journey. There were pro's and con's of each but I had to prioritise which of my user's needs were more important. Ultimately, I leant more towards structured, linear journeys as they seemed to be the norm for other learning experiences.

Breaking down LittleBits and seeing how they could be applied to teaching beginners coding languages. I made sure to pay attention to LittleBits when researching potential ways of replicating things digitally for beginners. I broke down how they could represent different parts of code i.e. batteries = the basics or the setup of code. This gave me the idea of working with "blocks of code" that I would eventually move on to play with, and take forward as one of my potential experiences.

Early app icon brainstorming. Originally drawing ideas of using the owl from the book Curiosity. 

A study on the various gestures I could utilise with a smartphone app.

Thinking about how to use search to help users reach their learning goals, or at least find their starting points towards working towards their learning goal.

Considering how applications could be linked together i.e. having a companion app on a tablet device which would act as the output, with the phone acting as a text-editor.

Exploring how to make user onboarding and engaging as simple as possible for learners to identify their interests when they first begin using the app and how to make the app personal to the user.  Making the app personal I feel adds that personal element which is important to make the user feel more at home and ultimately work towards creating a better user experience.

Planning the information architecture and the user journey. Also deciding what parts of the application to focus on prototyping. 

Rough sketches of what the overview page of the app would look like.

Downloading content to phones seemed like an important issue to think about since applications ultimately would work better if they can function just as normal with or without an internet connection. The ability to download content to phones seemed like this would be a solution.

Personal Honours Project - Creating Personas

Before sketching my ideas, Andrea suggested that it would be beneficial for me to create personas of users that I would expect to use my app. This would give me a better idea of how to shape the experience for a variety of learners and try and meet their specific needs.

Fortunately, on the Tuesday (26th of January) we had a workshop with Drew Hemment called Outreach and Impact in Interaction and Product Design which was centred around designing effective engagement and communication for our project work. As preparation for the workshop, Drew had us create personas for either a user, audience or stakeholder in our projects. He wanted us to create personas with a variety of details including:

  • Name
  • Role
  • Gender/Age
  • Interest - what relevance does your project have to them?
  • Stake - Describe any relationship in your project
  • Needs - What needs or requirements does this user have for your project?
  • Technical/Research literacy - How literate is this user with research/technology?

With this in mind, I created my 3 personas for my project.

Bright Beginners are confident learners who are very self directed when it comes to their own personal learning. As a result, they need an experience where learnt knowledge can be applied as they learn to reinforce this new knowledge. As they are fast learners, they need the basics explained clearly but should have no restrictions on the pace of their learning. They would also appreciate no restrictions on what they learn and when, as they want more control of the direction of their learning. Bright Beginners usually have a clear learning goal in mind and want to achieve their goal as quickly as possible before setting a new one. If they reach a particular topic that they are unfamiliar with and are struggling with, they will need clear communication channels that provide straightforward answers to get them back on track.

Anxious Amateurs are users who are traditionally used to formal education and are unfamiliar with self-directed study. As a result they are more anxious about using this type of service and may need more reassurance and guidance on where to go next than other users. They need the basics clearly explained and maybe subtle guidance on where to go next to reach their learning goal - as Anxious Amateurs do have a learning goal they would be more at ease knowing which specific path they will need to take to reach their goal. Like other users, if they reach content they are unfamiliar with they will require clear communication channels to access help and require straight forward answers to their problems. 

Free Fledglings are confident in their abilities to moderate their own self learning but are more interested in using the service recreationally as opposed to a serious learning tool. As a result these users would prefer no restrictions on what and when they learn about topics - preferring to 'browse' content at their own leisure. They are not looking to apply their newly learnt knowledge necessarily. Free Fledglings have no learning goal in mind and are using the experience purely to satisfy natural curiosity they have about topics and are willing to see where this interest takes them. Since they are working on their own timescale there is no pressure for them to achieve their eventual learning goal and will opt in and out of the service when desired. Likewise, they will unlikely utilise communication systems to find answers - if they struggle with topic they are more likely to move on or abandon the topic. They may however use the communication systems as a social tool.

Personal Honours Project - First Advisor Meetings

After a quick holiday and feeling refreshed and recharged, I found out that my advisor for my project would be Dr. Andrea Alessandrini who I was excited to work with.

Deciding to hit the ground running by planning ahead, I had my first tutorial with him on Monday the 25th of January. The main issue we had to discuss from my presentation feedback last semester was narrowing down what my representative content would be for my app - I would be able to craft an experience but without any content to interact with the app would ultimately be useless. 

In terms of representative content, I had hit a total wall and was struggling to nail down what exactly my content should be - I was very keen to try and design a service or experience that could allow you to learn anything you wanted, but for the sake of the project I knew I would not be able to achieve this to a high standard given the timescales for the prototypes. I'd had some ideas about what I could potentially explore during the holidays but I was very anxious about my project becoming "pigeon holed" and that I would become "the x project" as opposed to the "the learning project" which I was much more interested in being known for. I knew I would have to bite the bullet though and choose a focus.

In my first meeting with Andrea, we brainstormed potentially interesting topics to focus on for the duration of the project. I mentioned that I'd considered teaching coding as potential content and Andrea really took to this idea, as it fit with his area of interest and research. Since my project was focussed on creating digital learning experiences for informal learning, we expanded this idea to have a focus on new ways of teaching adults to code who have had no formal education (i.e. no prior study of Computing in schools/university). 

The main question Andrea asked me to consider is how would you break coding down to then teach beginners? Could a puzzle element be introduced or some sort game to make it easier? Andrea gave me the prototyping tool Little Bits to play with, which is a way of teaching children how to make circuits without the need to programme them. Each piece can snap together and when powered can create circuits similar to those of basic Arduino circuits i.e. led, buzzers etc. This would be something to consider when I was sketching my ideas.

Before that stage however Andrea said that I should spend this week working on narrowing down my target audience and creating personas based on this audience to meet a variety of user's needs.

Personal Honours Project - Learning about Learning (2)

Finally, I began to research informal learning or "casual everyday learning". FutureLab recently did a review of the current landscape of adult informal learning using digital technologies. One of the main importances of informal learning, as found by the report, is that informal learning is an important part of individual's learning journey.

Informal learning is defined as "happens outside the curricula offered by formal and non-formal learning activities". It can happen anywhere and occurs at any point from birth to old age. Another example of informal learning is teaching yourself to speak a new language. The informal learner is the self-motivated and self-directed learner and usually defines their own learning goals. 

In the UK, 94% of adults have taken part in some kind of informal learning activity in the last 3 months. This shows the extent of adult informal learning. In a survey conducted to find out the reasons for learning, the results included:

  • I enjoyed learning - 48%
  • To pass the time - 37%
  • To keep my brain active - 33%
  • To be well informed - 26%
  • Due to the need to find something out - 22%

The extent of the use of technology for informal learning shows that currently adults spend 15 hours a week on average learning informally. 79% of all adults say that they use technology of some kind while learning. 82% of men are more likely to use technology in comparison to 77% of women.

Technology that adults use to learn informally includes 15% of mobile phones. As technology develops, learners will be able to access all the services they get from internet on their mobile device. The devices can also be used to send information to multiple platforms in a variety of different ways - phone calls, texts, messages etc. They are also capable of sending different types of information including videos and images. 

75% of respondents were able to cite at least one benefits of using technologies for informal learning including reasons such as it's quicker to find out new things/saves time (37%), I can find out more information (34%) and I can learn when I want (31%).

When used effectively, digital technologies can play a crucial role in enriching and diversifying the adult learning journeys. However, there will be several design challenges I will face (according to the report) when trying to promote the use of digital technologies for learning. The main challenge is digital inclusion:

  • An estimated 17 million people over the age of 15 in the UK do not use computers and internet yet 90% of new jobs require IT skills.
  • 15% of the adult population (over 6 million people) suffer both social exclusion and lack of engagement with ICT.
  • Just over a half of non-internet users are over 65 and 66% of non-internet users lack higher education. 

Lack of digital inclusion and other barriers is preventing 44% of people in the UK from using technology to learn informally.

The report recommends a number of areas for research including how to explore and support the use of technology to transform learning. The report also cites Mitchel Resnick (2002):

"While new digital technologies make a learning revolution possible, they certainly do not guarantee it."

He also suggests that we we need to ensure that digital technologies are not used to reinforce outmoded approaches to learning.