You’ve been spending plenty of time together. You’ve had your ups and downs. As time’s gone on you’ve realised you like the way things are going and it’s time to commit.
Writing effective, communicative commit messages can make the world of difference to other members of your team. Just as with code comments or clear variable and function naming, good commit messages are worth putting some thought into.
First and foremost focus on communicating why the changes are being made. It’s easy to think commit messages are actually about what has changed, but reviewing the code will show you that. Why the code has change lets people know the intent of the change rather than the details of it. Good examples of commit titles are:
Update interface to the new branding
Add Dutch translation
Remove reference to Batmans true identity
Add GDPR compliance message
Once you’ve nailed your title follow up with a good description. For example:
Remove reference to Batmans true identity
The copyright text on Batmans website specifiys the copyright holder as “Wayne Enterprises”. This suggests that Batman has some association with the organisation. This update removes all connection between the two entities, protecting all parties. This fix addresses issue #391.
As you can see this message doesn’t contain any details about the code. It clearly highlights why the commit is being made and also connects the commit to a reported issue if one exists.
Over the years everyone will develop their own beauty routines when it comes to their individual coding.
While it’s easy to become attached to how you like to format your code, in a team environment it’s really important to share the mirror with teammates.
Having an agreed set of standards on how the code will be formatted goes a long way to improve its legibility. If one person is using tabs, and another spaces, then things can get ugly fairly quickly. Of course, this sort of formatting can be done manually, but we’re not wild animals so we can just get the computer to do most of the work for us.
Most text editors have multiple plugin options to take care of this sort of thing. There’s even a standard called editorconfig that allows different developers to work on different projects, even using different editors. Using the editorconfig standard a developer can automatically conform to whatever the standard is for a particular project without much of a song and dance.
To my mind understanding how to effectively work with others on a coding project is as important as the coding itself. Also understanding how people work is always good when managing people is part of your professional life.
To that end, since I’ve recently created an “app” and put it on GitHub, the obvious next step was to record any issues with the app. So far there are three, but I suspect there are plenty more.
I’ve been using GitHub for a while now as part of my spelunking into the world of VR and Mobile development. I think it’s fair to say it’s done a great job of protecting me from the inevitable mistakes of learning something new. Having said that, it does take a while to get your head around anything other than the basics.
Thankfully there are a large number of resources available to help you along the way. Most recently I discovered GitHub Learning Lab, a fantastic resource for learning how to use the platform for your own projects or contributing to others.
I think the thing I enjoy most about this particular option for learning is that it’s actually using the tools themselves. Yes, there is text and video to consume, but you actually use GitHub itself to work with the course material. I’m a real learn by doing sort of person so this sits particularly well with me.
So if you’re new to GitHub, or just want to solidify your knowledge of it, I suggest you take a look.
VR working properly again (at least I think I have)
select objects again
the FPS back over 60
Unfortunately I still can’t compile to my phone but hopefully, the weekend sorts that. It’s funny how breaking this thing has been possibly the most educational part of the course so far. I’m not saying I’d make a habit of it, but it was a net positive overall.
Making stuff is difficult, especially when that stuff is new. This is something I’m all too aware of. I was progressing nicely with my Night at the Museum project when (in my wisdom) I decided to upgrade my production tools mid-project. A word of advice, never do that.
Spending hours fixing a long list of issues is frustrating, but it isn’t a total loss. The key to success when you hit a bump in the road (like sucking at it, hating self etc) is to keep going! It’s not always easy but if you ever want to get good at anything, the key is preserving. Even in the face of self-loathing and a general distrust of your own abilities.
When you’re doing something new, embracing the tough times and roadblocks as an opportunity is key. You’ve got to see it as a way to toughen your resolve. If you can’t turn adversity into a win, then that adversity will win and you’ll stop progressing.
So the next time you find yourself making a virtual museum experience and your:
VR cameras stop working
you can no longer select items
your frame rate drops to a nausea-inducing 27 fps
you can no longer compile to a device
all of the above is your fault because you made an idiotic decision
delays cost you $300 per month in additional course fees (seriously send money now!)
Don’t give up, keep going! Not only that, tell other people about it. Seeing other peoples screw-ups is encouraging to others on the path to something new.
I’m working on a project for my studies with Udacity. The goal is to create a VR experience that demonstrates my research into a VR company. I’ll do a series of posts on this as I progress along the path to completion.
To start here’s my first crack at the initial documentation for the project:
Statement of purpose
The purpose of the "Night at the museum" application is educate the user on the HTC Vive VR solution. The experience is based on an exhibit style scene, which contains 5 "stations", each covering some aspect of the HTC Vive.
The target audience for this application is anyone interested in VR that would like to learn more about the HTC Vive VR solution. Here’s a basic persona from them:
Name: Wade Watts
Role: Budding VR enthusiast
VR Experience: Experience with google cardboard but limited beyond that
Quote: "VR is very exciting, I can't wait to learn more"
About this person: Wade has grown up with computers, game consoles, tablets and smart phones. He's a digital native that loves to escape into his devices. VR is the ultimate expression of that escape.
I’ve started by looking at different museum and exhibit styles to select a something that fits the aesthetic I’m looking for. After looking at altogether too many museums (if that’s possible) I eventually settled on classic Greek style building with exhibits setup like sculptures on pedestals. I’m using the following images as inspiration for the design:
I like this style, it reminds me of some of my favourite museum tours, and I’ve also done some work in a previous project that shares a similar style. This should allow me to reuse some of the assets from that project, meaning I can move faster. Always important when you’re pressed for time.
Having established a concept for the style of the experience a setup to make a concept build. Using the assets from previous work made putting something workable together relatively easy.
I added a terrain GameObject with a few mountains in the distance to give the scene a sense of depth. I dropped in a “temple” model that is a good fit for a museum and added a few items to flesh out the concept. For the actual stations I acquired an HTC Vive model from sketchfab user Eternal Realm. I also kept an eye out for the scenes frame rate to make sure I wasn’t introducing anything at this early stage that had a big impact on performance. I still have a few more models to acquire but I’m happy with the direction the concept is heading in.
Now that I’ve got the basics in place the next thing on the agenda is the first round of user testing. I shouldn’t have to much trouble acquiring a suitable test subject to get things moving. I will be interesting to see how the scene changes and progresses over the course of development.
Over the past few months I’ve been studying with Udacity to learn VR software development. The course has been great so far, so I thought I’d share a little of what I’ve been up to with a game called “Puzzler”.
Puzzler is a simple VR experience for Google cardboard. Basically anyone with a phone and a $15 cardboard headset can give it a try. The game has a simple UI where the user is thrust into a dungeon, where 5 magic orbs present a puzzle. Successfully playing a single round of “Simon” gets the player out of the dungeon to victory.
Here’s a brief video of the “final” version of the game:
Of course, I didn’t just wake up one morning and build this thing. There is quite a process to go through to create a good VR experience. As I mentioned on this blog before, a good process can make all the difference when you’re building for someone that isn’t you. Which, let’s face it, is almost always.
The approach taken for this work was no exception so let’s break it down a bit.
Statement of purpose
I started the process by creating a simple statement of purpose for the game:
Puzzler is a mobile VR app which gives new VR users a quick taste of VR via their existing smart phone. The entire experience should take no more than a few minutes and be accessible to most anyone that's physically able.
With this in mind, I selected the nearest available human to be a test subject and personify my ideal target audience. My 6-year-old daughter Emma was the winner on the day. When starting out the build, first I documented a little about her, so I had a clearly defined outline to work too. Here’s the persona for Emma:
VR Experience: Has played a few simple VR games, but not many
Quote (that sums up their attitude): “Can I play with your phone thingy, it’s cool.”
About this person: Emma is an enthusiastic VR user, she loves to explore and have adventures. She’s young and enjoys content that's exciting and interesting, but not too scary or intimidating. She will ask lots of questions and enjoys the discovery. I think it's fair to say she has moxie.
With a clear purpose and audience/persona defined it was time to get going with an initial design and an “alpha” build of Puzzler.
I started by creating a bunch of really nasty looking sketches for what puzzler might look like. And when I mean nasty I mean nasty.
Here are a few concepts I had for the game initially:
The all in one design
Just the finish
Just the start
Door from front and back, island theme
Door from the front and side, mountain theme
Door either end, generic theme
My thinking with the above designs was my audience is young. Given that, it was better to use a large simple UI that could be easily understood and a very simple scene design that wasn’t overly difficult to understand. Once I sketched out something I was happy with I then took the designs and built something in Unity.
With the first cut done it was time to get going with user testing. It’s so important to get an early version in front of your audience to test assumptions. My early tests were really all about determining the basics, like the scale of the scene in relation to the subject.
Basically, from there on it was a process of iterating on the project. A mix of making assumptions, asking questions, and testing it all as often as was practical. To give you some idea of the things I asked, here’s a few of the Q&A sessions I had with Emma:
User test 1
Me: How big do you think you are in this scene?
Emma: I feel a bit smaller, normally I think I’d be taller than that barrel. I feel little.
Me: What’s the mood or atmosphere of the environment?
Emma: A bit spooky, but I like the purple balls. Not too scary, there are no witches, I don’t like witches. It’s a bit bright for a dungeon though.
Me: Is there anything you find difficult to see, or anything visual you think could be improved?
Emma: No I can see everything, but I can’t hear anything should I be able to hear things?
Conclusion: Emma picked up on the spooky dungeon, she was feeling too small so I adjusted the player's height slightly. I moved the orbs to be closer to the player since Emma liked them so much. I also added some sound to the environment.
User test 2
Me: How big did you think you are in this scene?
Emma: I think it's right. I'm the right height.
Me: What’s the mood or atmosphere of the environment?
Emma: Spooky, the sounds are spooky, it sounds like night time. It’s a bit dark.
Me: Is there anything you find difficult to see, or anything visual you think could be improved?
Emma: The balls are too close to me. I feel like I’m going to bang into the balls.
Conclusion: Emma feels the right size now, but I think the scene is a bit too spooky for her now and the orbs are making for feeling a bit close. I’ll move the orbs to a different location and increase the lighting a bit so it's not so scary.
User test 3
Me: How do you feel about the scene
Emma: It looks cool, I like the lights, it feels dark outside and spooky inside, but warmer.
Me: Do you understand how to start the game
Emma: Yes I click the big “Start”
Me: Do you know how to play the game?
Emma: Yes it's like “Simon says”. I do what the puzzle does.
Me: Is there anything else?
Emma: The balls are in the way of the door. I have to crash into them when I win. The game is too hard for me.
Conclusion - The game has matured to the point Emma is happy with it and can play it well, she still isn’t happy with the placement of the orbs so I’ve moved them back and did a quick retest, she’s now happy. I also reduced the complexity of the game to 5 steps.
Breakdown of final deliverable
So, in the end, we’ve got a dungeon puzzler that isn’t too scary for a 6-year-old to play. Emma likes the game and can successfully play it.
The basic break down of the “final product” is:
The user is presented with a simple UI screen to start the game.
On clicking start the player is moved into the dungeon where they are presented with 5 magic orbs. Emma’s feedback had a significant influence on orb placement and the feel of the dungeon.
The orbs chime and blink in a random sequence which the player must complete to “escape”.
If the player fails to repeat the sequence a “fail sound” plays, and the puzzle is repeated to give the player another chance. If they get it correct they’re moved out of the dungeon and are presented with congratulations and the ability to restart.
Over all, it was a fun educational exercise doing this project. Plenty of things to learn from a process perspective but also in Unity 3D development. The work has given me a few ideas for other projects to experiment with, and further solidified my view of user testing and rapid iterations in the development of a product.
Next I think I’ll move on to a new project, but stay focused on something for that target audience. I think it would be of value to include a few more testers, including Emma’s brother and friends.
If you’re interested in playing around with the above project I’ve shared the source code via bitbucket. The other projects I’ve done via the Udacity course are also available on the Geekpulp bitbucket page.
As I said in my previous post on process, it’s important to test your work early and often. This means getting in front of your users and collecting feedback, aka UX testing.
When you’re starting out with user testing it can be quite intimidating, but with a few tips and a bit of preparation, it can be very valuable. There are a few basic things to consider when carrying out tests.
Asking the right questions
Just rolling up to your user and asking questions may provide some value, but it may also give you some bias or low-value results. To avoid this it pays to prepare your questions in advance of the interview. When formulating the questions themselves make sure you avoid both leading and dead-end questions.
An example of a leading question is “do you find the mood of the scene magical?”. By asking a question in this way you’re influencing your user to think of the scene in a magical context. This may affect their answers, reducing the value of the feedback. A better question to ask would be “can you describe the mood of the scene?”. It’s more open-ended, leaving the user to describe the mood without bias.
Dead end questions
Likewise asking dead-end questions also provides little value. Dead end questions are questions that can be answered with a simple yes or no. An example would be “did you enjoy the experience?”. A better option would be “tell me about the experience?”.
If need be, you can always ask any follow-up questions to clarify anything you feel isn’t clearly communicated in the users’ answers.
On the surface, you’d think you’d need dozens and dozens of users to test on, and in the past, many UX practitioners have done just that. As it turns out, that really isn’t needed. In fact according to a study by the Norman Nelson Group you’re actually wasting your time with big sample sizes. You’re actually far better served by performing multiple small tests on 3-5 people. Not only is it cheaper and easier to do, but it’s actually more effective.
The making of a “thing” happens in loads of different ways, but I’ve always found it’s best to have some sort of process to get a good result. It doesn’t have to be onerous, just something repeatable that considers a few things consistently.
To avoid an overly long post I plan to write a series on this subject. Here’s a few tips to get you started:
Start with people – It’s always tempting to just start building stuff, but you should always start with your target audience. That is the audience you intend to use you’re app. It’s easy to think it’s “everyone”, but is that really true? What experience do they have with VR/AR? Also consider this is a physical medium, so you may be making greater physical demands of your audience than with other digital experiences. Jumping may require users to physically jump, their height may be a factor, and so on. Simply writing a few sentences describing who your user is and what you expect them to do can be very powerful. For example:
The end users for ProjectX are likely to be people who are new to VR, but who have already experienced various games in their life. They are probably going to be 25-35 and own a smartphone. They'll be expected to stand, reach, jump and turn with relative ease.
Develop personas – I’ve always been a fan of personas. They are simple to put together, and make it easy to conceptualise your audience. Something to be aware of though is that personas by their nature are a generalisation of an audience. They will never cover all of the details, so you should expect to continue to refine them over time. With this in mind start with something simple you can build upon. Something like this:
VR Experience: Little to none
Quote (that sums up their attitude): VR looks interesting and I’d like to give it a go.
About this person: Anna is a highly educated working mother of two. She has a busy lifestyle but is always interested in new and interesting things. She prefers to try things before jumping in head first and enjoys things she can share with her family.
Statement of purpose A good statement helps us understand what we are building by defining simple project scope. It should be concise and ideally no more than one or two sentences long. It’s something you should keep visible to constantly remind you of what it is your building, and limit the temptation to go too far beyond that.
Here’s an example purpose statement:
ProjectX is a mobile VR app which gives new VR users a quick taste of a VR via their existing smartphone. The entire experience should take no more than a few minutes.
Make disposable concepts and iterate – In the beginning, everything you do should be simple, quick, and disposable. Use materials, tools, and techniques that enable this. Pen and paper are a surprisingly useful and versatile tool set. Expect to be wrong, it helps you keep an open mind on other options, not becoming too attached to any one thing. Iterate, iterate, then iterate some more. Eventually, you’ll find something you’re happy to move on with. Steadily increase the complexity and sophistication of your work as the idea solidifies.
Share your work early and often – You know who your audience is, show them what you’re making. Their feedback will be invaluable. You’ll also be able to get in front of complexity before things become difficult to change. While you’re with your audience take the opportunity to grow your understanding of them and update your personas to match. Note: Be careful to listen for what your user wants, less so how they want it.
Conclusion – Using these simple steps and methods is a great way to start any project, but don’t be afraid to change things up until you find a process that works best for you. Ultimately you need to find what makes your product better for your users and discard the rest.