Mobile App Project 1 Milestone 2

I started off Milestone 2 of our first Mobile App Development project by reviewing my last blog post and the feedback that I received from our instructor and my classmates. The goal of this milestone is to create a digital prototype or mockup for our app, so that we can demonstrate how the app might look and feel. I also need to start thinking about the logic and algorithms behind my app, so that when it comes time to actually start writing code, I can hit the ground running. Last, I need to include any content for the app, including assets like launch screens and app icons.

Feedback on Initial Idea:

The first pieces of feedback I received were from my instructor. She suggested that I might need to limit the categories of my app to avoid having too much content to manage, and that I should avoid having a “Restart” button, instead presenting users with  a back button if the user wants to change their generated idea. Since I was thinking about launching the maps app to give instructions to my users on how to get to each location, she also brought up the fact that I’ll have to handle the case of the maps app not being on the user’s device.

In class, I also got a useful bit of feedback from my friend Jen. She said that if the “Directions” map-launching feature is too hard to implement, I can just put the address on each idea page as text, because the iOS system will automatically recognize the address format and give the option to either open the address in Apple Maps or, for people who don’t have Apple Maps installed, the option to copy the address (and then paste it into a browser or a different app or something). I thought this was a good idea because it should work for every user whether they have Apple Maps installed or not, and it might be easier to implement then an automatic-maps-launch button. That being said, I still want to try to get the launch feature to work when I start to develop the app, but if it proves to be difficult, I have a solid backup plan.

Getting Started

Right away, I realized from Aileen’s feedback about content that if I build my app as described in my first blog post, I am going to have to deal with a huge number of different combinations from all of the different user inputs. It would be way too much content to generate and manage, especially once I got into developing the algorithms that generated ideas. So, I got to work by simplifying things a little bit.

At first, I wasn’t sure which parts to simplify. I knew there were way too many activity categories (in my first version, I had wilderness, urban outdoors, tourism, sightseeing, exercise, entertainment, cultural/history, and tours). But I also knew that I needed to cut down some of the other user inputs, because having four options each for “Budget”, “Amount of Time”, and “Season” was going to be way too much. Just to have a unique idea for each combination of choices, I would need 4*4*4 = 64 ideas, and that’s without accounting for different categories! Since I’m going to be generating an image, a short description and (for most of them) an address for each activity idea, I needed to drastically simplify my user inputs.

Since I didn’t know which options I should scrap, I started off by brainstorming ideas that would actually be generated by the app. This way, I could see which categories were most relevant and build my app around those. With help from my brain and the internet, I came up with 35 ideas and sorted them into three categories: Outdoor Exploration, Urban Attractions, and Entertainment. I had at least 10 ideas for each category, which I was happy with.

Ideas!

I also went through my ideas and determined which ones would be restricted by season, and I realized that most of my ideas actually work in most or any of the seasons. This lessened my anxiety about having enough unique ideas for each combination of user input, because a large number of my ideas work for various different combinations.

I also decided to scrap the “Amount of Time” variable for user input. This simplified things, and I realized that most of my ideas were flexible enough that a user could choose for themselves whether they wanted to spend a few hours or longer doing the activity.

To simplify the “Budget” variable, I narrowed the user input down to two options. The new question asks: “Are you willing to spend money?” and the user can choose “Yes” or “No”. In my original idea, there were four different options for budget, from free to cheap to expensive to really expensive, and I don’t think that level of precision is necessary or useful for this app. With only two options, things are simpler for the user and the algorithm. If a user selects “No,” they will still get to see all of the free ideas, and if they select “Yes” they will receive an idea out of all the free ideas and all of the paid ideas.

Content

My full list of 35 ideas can be found below. When I actually start building the app, I’ll just have to find an image and write a brief 2-3 sentence description for each one. I’m pretty familiar with all of them, so I hope that part of the process won’t take too long. There are 12 “Urban Attractions” ideas, 13 “Outdoors Exploration” ideas, and 10 “Entertainment” ideas.

1. Rock Climb in Boulder Canyon
2. Visit Eldorado Canyon State Park
3. Drive Trail Ridge Road in Rocky Mountain National Park
4. Snowshoe in Indian Peaks
5. Hike to Boulder Star
6. Shop on Pearl Street
7. Paddleboard at Boulder Reservoir
8. Beach Day at Boulder Reservoir
9. Mountain Bike at Betasso
10. Hike to Royal Arch
11. Run in Chautauqua
12. Visit Denver Botanic Gardens
13. See the Denver Zoo Lights
14. Visit Denver Aquarium
15. Play at Water World
16. Play at Lyons Classic Pinball
17. Visit CU Campus
18.  Tour Avery Brewing Company
19. Catch a CU Shakespeare Festival Show
20. Go to a Concert at Fox Theater
21. Shop at the Boulder Farmer’s Market
22. Stargaze at Brainard Lake
23. Chill and Read at Boulder Public Library
24. Visit Boulder Falls
25. Watch a Show at Fiske Planetarium
26. Explore Shops on the Hill
27. Catch a Game at CU Events Center
28. Tube Boulder Creek
29. Dance at the Boulder Bandshell
30. Watch Pearl St. Entertainers
31. Watch a CU Football Game
32. Visit the Denver Art Museum
33. Catch a Concert at Red Rocks Amphitheater
34. Watch a Movie at Century Theaters
35. Walk or Ride the Boulder Creek Path

Assets

After creating my content, I decided to start building the assets for my app to establish some visual branding before diving into the real prototype. I liked the idea of the name “MyBoulder” for the app, since it is all about finding new ways to explore and have fun in the city of Boulder. It’s a little cliche, but I wanted to use some imagery of the Flatirons in the app logo since they are such an iconic representation of the town. I started off with some sketches, trying to work the letters “M” and “B” (from “MyBoulder”) into a Flatirons-esque shape.

Sketches for icon idea and logo

Final sketched version

I threw my sketch into Illustrator, found a gradient that I liked, and vectorized everything to create a first attempt at an app icon/logo:

Next, I went into InVision Studio with a transparent version of the logo, created a similar gradient and positioned everything to create a launch screen prototype:

Prototype/Mockup

Feeling good about my visual branding now, I moved on to creating the prototype itself. It took a little while to remember how to use all of the features of InVision Studio, but I quickly got back into it and a few quick Google searches helped me get up and running.

I used an iOS UI kit specifically made for InVision Studio to quickly create iOS-styled components, which greatly sped up the prototype-making process. The only real problem I ran into during this process was that when I clicked into some of the smaller components, like each segment of a segmented control, InVision didn’t let me create “interactions” (triggers to go to a new screen or play an animation) with the smaller components. I solved this problem by simply creating an invisible box to place over the segment and using that box to trigger the screen change instead.

After that, the biggest problem I had to solve was the fact that I couldn’t design a prototype that would allow a user to click whatever they wanted on the first screen. There are simply too many possible combinations that the user could pick that I would have to design screens for. Thus, I decided to show two different examples of selections a user could make. If the user ever gets stuck on my prototype because they are clicking something that should change the screen (ie. a segment on the control or a switch that I didn’t activate), InVision helpfully highlights clickable areas of the screen in blue to guide them. This inability to design for an unpredictable variety of user interactions is just a limitation of InVision that I’m not sure how to get around. However, I am confident that my prototype demonstrates a solid example of how the flow of using the app would work, and the user can assume that the real version would have every button and control be clickable.

Check out my finished prototype here: Live Prototype

Again, if you get stuck, click somewhere on the screen and InVision will highlight the areas that you can click on in blue.

Logic and Algorithms

Now that I had my content and prototype complete, the last thing to do was to sketch out some pseudocode for how the app would actually generate an idea based on the user’s input. I used Github Gist for this. The general idea is to store ideas in structs, with basic information like description, title, address, etc. Then, I can store all the ideas in a master array. When a user clicks the “Let’s Go” button, I will iterate through the master array and add qualifying ideas to a new array, which I will use to randomly select a qualifying idea to present to the user and load into a new page.

	// Each pre-defined idea will be stored in an object that has a title, an image,
	// a description, an address, a category, and various booleans for season compatibility
	// and whether or not the activity costs money.
	// Example:
	struct Idea{
	var title : String = "" //name of activity
	var imageName : String = "" //name of image for activity
	var description : String = "" //short description
	var address : String = "" //address of activity location
	var category : String = "" //can be "outdoors", "urban", or "entertainment"
	var summer : Bool = false
	var fall : Bool = false
	var spring : Bool = false
	var winter : Bool = false
	var paid : Bool = false
	}
	var firstIdea = Idea()
	firstIdea.title = "Paddleboard on Boulder Reservoir"
	// etc.
	// Obviously, I'll have to figure out a way to make this process more efficient
	// for inputting ideas, probably with a constructor. I'll most likely store all
	// of these Idea objects in a master array.
	var masterList : [Idea] = [firstIdea, secondIdea … etc.]
	// Once I have all of my events in an array, I can iterate through the master array
	// and add ideas to a new array if they meet the user's criteria.
	var selectFromThisList : [Idea] = [] //make new array
	// Make some variables for user preferences
	var season : String = "summer"
	var userIsWillingToPay : Bool = false
	//etc.
	// Use these preferences to iterate through master list and select qualifying ideas
	for idea in masterList{
	if (season matches and category matches and price matches){
	selectFromThisList.append(idea)
	}
	}
	//select a random idea from selectFromThisList array and pass it to next screen to load in info
	var length : Int = selectFromThisList.count
	var selectedIndex : Int = use math to select a random number in the range of 0 to (length – 1)
	var selectedIdea : Idea = selectFromThisList[selectedIndex]

view raw

MyBoulder.txt

hosted with ❤ by GitHub

Alright, I feel like I’ve fleshed out plans for the main components of this project. Here’s to hoping that the actual implementation goes well too!