You know what's better than a powerful computer in your pocket that can do a lot of what you do on your laptop? A powerful computer on your wrist that can augment a powerful computer in your pocket that can do a lot of what you do on your laptop!
We will compare and contrast Google's and Apple's strategies, hardware, and software. We will also look at where smartwatches began. We'll also get into wearable, personal computing at large.
As we discussed in the monetization lecture, determining which platform to build for can be a tricky decision. There are several aspects to consider:
Which platform has the most users? Android, definitely.
Which platform has more stuff in the app store and makes it harder to find things? Again, Android. Definitely.
Which platform is more expensive to develop for? iOS. (Macs are not cheap, plus $100 a year.)
Which platform makes the most money for developers? Probably iOS.
So, the answer than many compaines come to is that they need to develop for both Android and iOS to hit more of their market. One way to do this is to have two dedicated teams, one for each platform, that collaborate on requirements and design. This is how many mobile shops like WillowTree opperate.
However, in a large company whose main business is not producing software, there's a desire to optimize the time needed to produce an app. Also, if updates need to occur, it's best to make those changes in one place. Hence the desire for cross-platform development.
Cross-platform development for mobile basically comes in two forms:
Build with an API/toolchain that exposes the native SDK of the platform for a single programming language/system (i.e. C# with Xamarin)
Build a hybrid HTML5 web app that can execute as an app on the device (i.e. Apache Cordova)
It is estimated that Google brings in $1.1 million per day
Over 2013, the estimate is $1.3 billion in 2013 (13% of what Apple did)
The Google Play Store, however, is 75% of all total mobile app downloads worldwide (App Store is 18%)
Much larger install base
More phones and properties
Currently growing at a faster rate than the App Store
Most profitable Android apps are doing better than the most profitable iOS apps
Spring 2017 Update
Highlight quotes from the article linked below:
90% of Google Play income came from games.
According to App Annie, the average user spent over 150 billion more hours in apps in 2016 than they did in 2015. The number of hours spent in apps totaled nearly 900 billion. That’s good for about a 15% increase overall.
Download numbers stopped being the big metric that developers and pundits used to calculate an app’s success. Things like daily active users (DAUs) and time spent in an app became the more important metrics.
The number of downloads increased by 13 billion from 2015. Total apps and games downloads were over 90 billion overall. That’s a growth of 15%. Much like 2015, Google Play saw more download growth than Apple. China also contributed about 80% of Apple’s download growth.
In 2016, India surpassed the US in overall downloads while Brazil and Indonesia saw good growth. Four of the top five countries in “time spent in apps” were also developing markets.
The idea of analytics is the gathering, processing, and interpreting of data. The concept of analytics is not new (consider any program you have used that asked to send data back to the developers), but the ready capability to do analytics with web services and cloud computing has made it now more easily available to anyone.
The code isn't all that exciting... the best part is that we can add events to actions that we want recorded. For instance, when you press the "Feature 1" button, here is what is called:
Toast.makeText(this,"Tychonievich is very smart. He likes Feature 1. So you are smart too!",Toast.LENGTH_LONG).show();Bundlebundle=newBundle();bundle.putString(FirebaseAnalytics.Param.ITEM_ID,"Feature 1");bundle.putString(FirebaseAnalytics.Param.ITEM_NAME,"Feature 1");mFirebaseAnalytics.logEvent(FirebaseAnalytics.Event.SELECT_CONTENT,bundle);
Now that you've seen the system in action, what sort of thing can and should we record about our apps?
There are two vectors to consider: who is using the app and what are they doing in the apps.
Let's start with the what. Software engineers call a profile and likelihood of how often certain features are used an operational profile. Operational profiles are incredibly important to manage how you build and maintain an application. Consider features like print and save in a word processor versus mail merge. Some features simply require more attention because they are going to be used extensively. How do you know what parts of your app people use the most? Wouldn't you want to know that? How would you use that data?
Then there's the who. If you could pair the operational profile with info regarding your users, then your development could be even more targeted. What aspects of a person would you be most interested in?
returning user vs. new user
how long people use the app
what device they use
what network are they on
What pieces of data would you want from your app to make it successful?
Between the information we gather through sensors and also through analytics procedures, we need to be fully transparent regarding what we do with users' data.
Gather - how will the app collect it's data; can the user opt-out
Use - what will the company do with the data
Disclose - will the company give (or sell) the data to other entities
Manage - can a user ask for their data "back" or even deleted; how is the data stored; is it archived
Today you will begin to create a digital wireframe of your final project app. Please upload a PDF copy to the root of your final project repository AND each partner should submit a copy to the appropriate assignment in Collab.
You can use whatever digital tools you would like to create the wireframe. There are dedicated wireframing tools available out there - some free, some pay. You are welcome to explore these options, or use something else, such as Photoshop.
How are users going to be using your app? What will they want to do? Come up with a list!
Step 2. Create a screen list
Based on the features above, come up with a screen for each feature.
Step 3. Refactor the screens
Now that you have the screens, how can you reorganize or revise them to combine similar features, link things together, etc.
Step 4. Figure out the screen relationships
Which screens are "siblings," in that they appear on the same tab bar and users can flip between them? Which screens are parent/child, such as a list of items and then the details of a particular item? Decide on these relationships and map them out!
Step 5. Plan your navigation and transitions
Where do you have "lateral" navigation between sibling screens? Where do you have "descendent" navigation to child screens? How will you make these transitions? Lay them out on your wireframe! Now, how do you go from one screen to the next? Tabs? Swipe left to right? A list of items? A button? How do you show your current state/location?
Step 6. Plan your reverse navigation
When do you want to go back a screen in the order you opened them, and when do you want to go "up a level" in your navigation tree? When is each appropriate? How do you know what the user wants? (i.e. temporal navigation vs. ancestral navigation)
Step 7. Draw it up!
Physical wireframes are great for getting your ideas down quickly! You can transfer to digital later too for more interactive designs to show clients.
Step "Should do this along the way"
Consider different screen sizes and orientations. You can repeat this process for each permutation as needed or you can do them as you go.
Today, you should work with a partner (anyone is fine) to draw a wireframe!
We are going to design an app for people to order food in a movie theater. Let's pretend that in this high-end theater you can order drinks, snacks, and meals right from your seat on your phone and a server will bring it to you. Consider a few things:
How would you show the menu?
How would you indicate where you are seated? (let's assume the theaters are relatively small and the seats are large with swing-up tables)
How would you pay? How would you give a tip?
How would the user do all this quickly without distracting people around them?
You can use your imagination to add features/constraints for your design. For instance, you might want to assume people purchased assigned seats in the theater or can link their ticket to the app.
Draw your app on the handouts provided and then you'll be called up front to share your designs!