Organic UI Design

I think Matt and I both mentioned last week the evening where we went through over a half dozen UI designs for a single screen while trying to figure out the best layout. In truth, we may continue the adjust the layout as we have in the past. Each time we do, however, it truly feels like it is getting better and better. Matt also showed, though somewhat difficult to see on video, our current final screen layout for the game board. We both thought it would be fun to do a bit of a slideshow in my post showing the progression of all those designs.


This first picture is how it looked before our discussions started. We had been using this design for probably around a month. It actually took a long number of hours for me to figure out how to rotate the graphics context so I could properly draw the card placeholder images sideways. This game board design had been the first one where I had actually written up UIView subclasses to deal with a character and their cards rather than about 15 different UIViews that I had to manage (per player, so 60 total).

2015-03-05_2The beginning of our long night discussing the UI layout of the game board began with this layout mockup. As you can see in the following image, the idea was to only show the other 3 players and have the cards on the table be my own cards. This was a holdover from the previous layout above. I’m not sure any of us really liked this (not having a permanent spot for “my” cards) but it’s what we had so we had kept moving with it.

2015-03-05_3Here is the “finished” design of the previous layout. Matt posted the first one while he was still working on it and I started making some comments on it while he continued to get the rest of the game elements in. As you can see in this mockup the center table cards (my cards, or another player’s cards when I want to view their cards) were rather small. On an iPhone 6+ it probably would have been okay, but on a 4s it was going to be extremely… small. The cards would have been only 1/3 the width of the device in landscape so it was a quick discussion to determine that they were going to be too small.

2015-03-05_4As we moved along the discussion, we worked through the fact that we needed a place to see my current calorie score. The thought with this one was, I believe, that if you tapped on any table-cards, that hand would then be brought up center in the table and the rest of the cards would disappear (so all 4 hands would be replaced by a single larger hand). This would increase the size of the cards, but due to the position of all the player images it still wasn’t going to be that big. Our limiting space with this layout was going to be the vertical space.

2015-03-05_5The next iteration redesigned the player images and scores to make room on the table for the “zoomed” cards to take up the entire table. Unfortunately this brought up the discussion about how we were going to zoom the cards in and out. Our initial comments were that they would tap the placeholder cards to zoom in and then have to tap a dismiss button to send them away. This would have made it extremely easy to know how to dismiss the cards, but was going to introduce an extra tap to everything the user did. To switch from my cards to another player’s cards I would have to tap the dismiss button and then tap the target player’s cards to zoom them up.

2015-03-05_6Continuing the discussion we covered the fact that being able to always see the placeholder cards even when a hand is zoomed in would be beneficial. This wouldn’t allow us to see the actual cards, but between the placeholder images showing which type of cards were played and the score showing how high the calorie count was we felt it would give enough information. However, we again decided that the zoomed in cards were back to being too small. We were trying to figure out a way to decorate the table with information level specific traits. For example, the layout you are looking at now is for the taco shop, hence the chips and salsa. We decided we were losing too much space just to put some chips on salsa in center table.

2015-03-05_7This is the current incarnation of the game board. It’s not done yet, we are positive we will continue to make changes but we feel this is another step closer to the final layout. It seems to give a good balance between an up close view of cards as well as a higher level overview of the entire game. There are a few elements not shown in this image such as the “whose turn is it” indicator that we are still working on. We currently have one implemented but we both felt it was not as useful as we hoped in its current location. It just doesn’t attract enough attention so we found we would be waiting for our turn when it was already our turn. So more things to work on.

Leaning towards a database

I did a little more research and some trial and error testing with Parse (more on this later). In short I implemented Parse into our game for now. We have not made a definite choice yet but so far it seems to be working rather well. At this point we have implemented the basic account management system and some statistical data tracking.

As we have been starting to talk through things like achievements, unlocking perks and new levels, etc. we have realized that we need some information on individual games to know what to do. For example, how long do we expect somebody to play Mealtime Sabotage before they unlock level 2 (whatever it is called)? One hour, five hours? Whatever time we come up with we need to know how long the average single player game is going to last.

We know multiplayer games are going to lost longer because you will have to wait for each player to take a turn. Single player, however, you only have to wait a total of 6 seconds between turns. Each A.I. player takes 2 seconds to play (though this may change in the future). If each game lasts 5 minutes then we need the player to complete X number of games. But if each game lasts only 2 and a half minutes, then we need the player to complete Y number of games.

Currently we are tracking our own game plays just to get some data. How long the games take, calories played, highest win, lowest win, number of wins vs. losses, etc.. The other thing this has allowed me personally is to learn more about Parse and figure out different ways of calling the API to get the results we want – without costing us a fortune in fees.

Due to some emergencies with our servers at the office I wasn’t able to get a lot done this week. I managed to get the Parse API implemented and fix a few bugs that Evan found in the game play. Hoping to get some extra work done over the weekend.

Week 3 : Daniel