[MUSIC] There's a lot of ways that you can leverage the iOS platform in your applications. And one of the things that you really need to make yourself familiar with, before you get started in developing multiple apps beyond just basic exploration, is knowing all the different features that iOS supports in its platform natively. By knowing those, you'll do a better job of designing your application to incorporate those, where it's appropriate. You'll find that a lot of the ways in which iOS supports developers has to do with creating common structure that multiple apps can interact with to achieve a consistent user experience when you're executing that kind of a function across multiple apps. So just at a high level there's a lot of functionality that's already built into iOS. And so in this lecture what I want to do is just walk through some of the features that are available to you so that if it comes time to build an app that uses one of them, you'll know that it's available and you'll be able to go find more documentation on it. Now all these things, it's not practical to have a project for every single one of these items. So we're not going to do that. But it is enough that you will be able to track down other resources if want to include some of these features into your application. And it wouldn't be a good user interface course if you weren't familiarized with some of them. Now the bottom line is, you don't want to reinvent the wheel. A lot of these things have already been built. And at first blush you might think, oh it would be great if we had an app that did this, and what you might be describing or what you might be imagining is something that's already built into the core functionality of iOS. If it is, use it. You're gonna deliver your apps much faster, and you're gonna find that they're more consistent with the rest of the platform. So, we need to think about what UI elements are for. What were they designed to do? And we wanted to make sure if that is what we are trying to get our app to do, we leverage them. So, we want to use the standard UI elements and we want to use them correctly. Why? Well, one reason why is because this platform is continually developing and if you were using the standard UI elements correctly, as the platform develops, whatever new graphics are associated with it. Whatever new functionality gets introduced, it will be designed the next generation of the iOS platform, will be designed to support apps from previous generations that you use the interface correctly. So if you're using it correctly, it gives you a little bit of support in the future as changes come to the platform. The second thing is that users already understand how to work with some of these standard UI elements from other apps and so you're leveraging their mental model and their understanding of the platform in order to make your app seem like it is better designed, has a better user experience. Standard UI elements can often be customized in a lot of ways, to give you freedom of presentation, look and theme, and brand name, and functionality, and still won't break the basic contract, the basic expectation of how that feature's gonna work in an application. So, here's an example, about how you would want to do that correctly, and how you can do it incorrectly. You don't wanna create a custom UI element to perform a task that a standard UI element already does. This can be seen in some of the graphical elements that are available. So here's an example of a graphic element down here at the bottom of the screen. This is a standard icon that's available to you in various buttons. You can select this. And when you select it what you're really doing is you're selecting a functionality more than you're selecting a picture, and that functionality in this case corresponds to the intention of refreshing or reloading. So you might see this at the top of a news feed or at the top of a browser, and the expectation is that it's used to refresh the content or reload new content. Now if you just treated that as a graphic, and you didn't think about what it was supposed to be used to mean, you might say oh, well that is also helpful for rewinding. Maybe we want to go to the beginning of our audio file. And we would like to use that to specify not rewinding, we want to use it to specify reply. So like in an email, we might hit it to reply back to the person who sent an email to us. Well that's not what this is for. This is for reloading. And so in a subsequent refresh of the iOS underlying platform, software development kit that icon might change and it might become something is consistent with reloading or refreshing, but stops meaning anything that looks like reply. So you wanna make sure that if you use standard resources, and if you use standard UI elements, you're using them for the right reason. So that if the graphic gets changed, if the use case gets changed in the future, it supports what it was supposed to be used for. So there's a bunch of these different icons in specific, although this practice extends beyond just thinking about icons. And here is a bunch of them. So for example, there's ones for delete functionality and there's ones for taking pictures, there's ones for uploading things to the cloud and downloading things to the cloud. Each of them has specific semantic understandings and you can find details of that in The Human Interface Guidelines that are available online. They are written by Apple. And in those human interface guidelines are a lot of instructions for what these different icons are meant to be used for, even if you feel like a given icon might be really good for getting you your travel information. That's not what that one is for, all right? So iOS UI technologies, there's a lot of them, and what I want to do is I want to run down some of them to make sure that you are aware of what's available to you in iOS 9, so you can leverage them in your applications. One of the first, one of the newest things that's available is 3D Touch. Now, 3D Touch is really difficult to describe in a presentation like this, because it's a very physical Interaction in which you manipulate an actual device in a way that's just kinda hard to communicate in a video. But basically, it's a pressure sensitive tap. If you have an opportunity to go into an Apple Store and test one of these things out if you don't have a device on your own. It would be helpful for trying to understand what it is that these function support. So there is two levels of pressure interactions with the phone. The first is a peak and that's a light press on an icon and what that does is it supports previewing content. For example bringing up photos or movies briefly. And it's temporary, so that if you lift up your finger it goes away, and corresponds to a light touch. Now a Pop on the other hand is when you press, you possibly get a contextual menu and you continue pressing as if you're pressing through the menu and then that's gonna activate this contextual menu that comes up. So Peek and Pop are two different kinds of interaction metaphors that are new with the force touch platforms on the newest hardware and on the Apple Watch, and there is built in functions and delegate methods for supporting that within the SDK. The next one to talk about is the Wallet. Now, you've probably see the wallet used to manage tickets and coupons, boarding passes and virtual cards. It's actually kind of this is kind of more common in Asia for smart phones, but Apple has started to get or has attempted to get into this market and Wallet is not a place where you pay for things, which is sort of confusing because it's called Wallet. Instead, Wallet is a place where different things that used to be documents will be kept now on your phone. Things that include tickets or coupons, boarding passes, virtual cards like virtual loyalty cards, can all be stored in your Wallet now. So here's a little example of some of the things that are in my Wallet, I can get this to play, see. In my wallet I have several left over, I have several Starbucks cards that have been given to me as gifts over time, no balance you'll notice. Lots of boarding passes here for different airlines. You can see that there are some bar codes for scanning with different loyalty programs like with Target, which is a department store. All these things interact with apps that I have on my phone, but the wallet is a central place where I can pull up the bar code. I can pull up the coupon. I can pull up the image of the barcode if I wanna scan to get into public transport, if I wanna scan to get onto an airline. So that's a functionality that is supported by Apple and it doesn't actually have to do with money, it has to do with documents and demonstrating documents. The next one is Apple Pay. Now Apple Pay does have to do with money. And this is a little bit like The Facebook single-sign on, and the social media single-sign on, in that by leveraging Apple Pay, what a user can do, is to put their payment credentials into their phone. And then apps can pay for things through Apple Pay without having to have a user give their credit card information to the app. Instead, they give it to the iOS device in one place and you can use it to pay for many different things. Now the reason that you're probably familiar for Apple Pay, if you're paying attention to the Apple ecosystem, is because you can use Apple Pay to pay for things at certain retail outlets by putting your phone near an Apple, by putting your watch near and Apple Pay reader, an extra cash register. So, what is, Apple Pay is not the fact that the watch can do that but that the watch has your credit card credentials loaded on it. Apple Pay is the same system that enables you to do in-app purchases if an app does in-app purchases. It also enables you to do real world purchases. And the bottom line is what's happening here is that Apple is keeping track of the credentials, so that the user doesn't have to give them to apps, which they might have not total trust in the app. So, it's like single sign-on, but it's used for payments. And once the user puts their credit card details and possibly their shipping information into the phone, apps can leverage that, and not have to collect the information on their own. ResearchKit is the name of a data collection functionality that is built into iOS. If you come from a research environment or a university environment where you do research projects, you may know about things like informed consent, about data security, about the needs to anonymize data when you're collecting data for scientific studies and so ResearchKit is one centralized place in the phone that enables you to do some of those things. So on the right here you see an example of a screening questionnaire, to see if someone is eligible to participate in a scientific study. And so ResearchKit provides functionality and support for confirming eligibility, for obtaining informed consent. For managing data access to appropriate people who can and can't have access to sensitive data. For conducting feedback and questionnaires about behavior. Usually that's the thing that the scientist is interested in finding out. And then giving dashboards to both the user and the investigators about what kind of data is being collected. So that's a functionality for supporting research studies that collect data from a user through the phone, that's called ResearchKit. App extensions are ways in which your app can do little bits of functionality in places around the phone environment that aren't used when running an app. So, for example, if you look at the today view by pulling down on your phone from the top. You can see that some apps have the ability to interact with this view. Out here for example is an app that I have on my phone called Dark Sky and Dark Sky is something that does micro weather prediction. And right here it's telling me what the forecast is going to be for the next hour. Below that you see a To Do manager called things. And both of these applications have app extensions that enable small amounts of their functionality to be delivered to the today view. So that's something that your app can do if you want. For example, maybe you have an alternate way of sharing things through some new social media. And if that's your app, you can add something to the app extension to support that. You may have a new way of editing content, and so you might have a new photo filter. And so you might have an app extension that's used in the today view or in other places, so that other apps can leverage your functionality. And you might have some new way of saving documents to the cloud. For example, services like Dropbox, so that within other context within the phone, not just in the Today view, other applications can leverage functionality that your app provides. Usually, it's because you're part of a larger service infrastructure. HomeKit is a little bit like ResearchKit. It is support within the Apple ecosystem for doing a particular kind of task. So HomeKit is about supporting automation in the home. You might be familiar with the Nest Thermometer. This is kind of a conceptual touch point for this kind of stuff. HomeKit is a way for you to write an app that can change the status of different devices and appliances within a home. For example, you can turn on lights with a HomeKit backed app. You can maybe adjust the music in your home or adjust the thermostat. When you're at work and you're gonna come home, maybe you left home, and you are in a hot climate and you left the air conditioning on, you're worried about wasting electricity. Well, if you had the appropriate connections, both at home and in HomeKit, it's possible that you could use HomeKit to turn off your air conditioning, maybe when you're on the bus, if you've forgotten to do that. And notably, it has Siri integration, so you can do things like use voice activation to turn on lights and music in your home. So this is a relatively new Chunk of iOS and it supports home automation, and something that Apple wanted to make sure they had the ability to participate in if that became a larger part of the world. Multitasking was introduced not too long ago, in particular, split view technology. So what we see here is, we see two apps running, and they've been split along a line here that enables them both to be used at the same time. There's kind of a primary application here with these four boxes, and then this map is operating in a multitask mode on the side. And this enables users to be using one map at me, look up some information or checking address or check a text message on the side without having to totally leave the context of their application. That's multitasking support. Social media sharing. We've seen this in previous courses in our previous lectures within this sequence. It enables users to login to social media, like Twitter or Facebook one time, and when an app would like to share some content from the app, they can just leverage the fact that the phone has already authenticated to Facebook, and so that authentication doesn't need to be managed by the phone anymore. And this is an example of an app extension, if you want to Twitter and Facebook are not, but this view is an example of a place where you can put extensions if you want. I'm not right, anyway. Okay, iCloud is a cloud-based persistent data storage system. It enables you to have a place where your information is stored in the Apple data centers. And your application perhaps running on multiple different of your users' devices can access that same information and appear to be working in one seamless information ecosystem. So you might have an application in which you author some content and you want to save it. In addition to saving it locally in a persistent store you can save it to the cloud and then later if the user or collaborator using the same app opens their app that can be synced from the cloud. So it appears that the data is consistent across multiple different platforms. This is more of a remote database style collaboration as opposed to being a real-time communication, a real-time syncing operation. It's more of a remote database where things can be stored or drawn upon. iCloud. HealthKit, not to be confused with ResearchKit. HealthKit is a place for individuals to store information about their personal health. A good example of this is if someone is interested in managing their weight, they could use HealthKit, which is an iOS repository of health information to keep track of daily measurements of their weight. Now HealthKit isn't necessarily the best way to collect that information and so a user could write an app that collects daily weight information, in some interesting and innovative way, but stores it in HealthKit. And by storing it in HealthKit, other applications that use the user's weight information can get that, and get that in a way that the user feels like they have control over and the ability to keep safe and private. HealthKit is building on the concept and the movement, which is called quantified self. This idea in which people are very interested in keeping a lot of detailed quantitative data about their health and their behavior. In an effort to kind of optimize their emotions, optimize their effectiveness, optimize their productivity. Optimize their health. So there's a huge range of different things that HealthKit keeps track of. From weight, to sleep, to caffeine intake, to anything you can possibly imagine. Some of it is very detailed actually. So there's a central location for health data which an app can put data into. Or can do things by requesting data from HealthKit, all with the user's permission, of course. Again, this is different than ResearchKit. ResearchKit is for collecting information for research studies. ResearchKit might interact with HealthKit but fundamentally, those are two different things. Okay, the next one to talk about would just be Game Center. Game Center again has this flavor of many of these different built in features where it is a place where you can store special kinds of information that's useful for the user to keep persistent over long periods of time. HealthKit is a more serious one, Game Center is a more fun or entertainment based idea. And this is a central place that users can store game progress, can store game scores, can connect with other friends who are playing similar games, so that they can compare their performance on the same game with multiple people, so that they can keep track of their performance if they wanna play one game on one device, and maybe pick it up on another device. So it's a social sharing information storage hub for games. Leaderboards and achievements being two ways in which this is leveraged a lot. If you are building an application and would like to make money on it, one of the ways in which you can make money is by displaying ads. Apple has built in support for ads and so you can leverage a library, a framework within iOS called iAd. And you can provide iAd with a portion of your screen real estate in which a ad can be displayed. And based on how the user interacts with that ad you can generate your own revenue. So this means that you give up some of your screen real estate Apple chooses ads to present to the user and if the user clicks on them, Apple gets money from the person who wanted to place the ad on the phone, and share some of that revenue with you as an application developer. Many apps use this as a revenue model, on the up side, it means that you do not have to charge for your app. On the down side, using ads in your application increases the bandwidth and the battery consumption of your application. Sound. Sound doesn't get talked a lot about in development courses, but the sound within an iOS app is kinda pretty sophisticated. That's a picture of an ear if you couldn't tell. I'm not an artist, I'm a computer scientist. And so, there are a lot of different ways in which sound can be played. There can be sound effects, there can be feedback, there can be notifications, you can also play media. And when you play sound within the iOS environment you have to specify what kind of sound you're playing so that the Silencing button on the side of a device can be appropriately used to silence the phone in the right cases and not silence it in other cases. And the general model for how iOS does sound muting, is that if a user proactively initiates the plane of sounds, usually it doesn't matter whether or not the little switch on the side has been toggled on or off because the assumption is if the user wants to play, wants to be silent then they're not gonna be trying to play a movie or a music actively. That's messed up. That is, that's caused some problems for people when they've been in situations where they wanted the phone to be silent and they expected that switch to keep it silent under all circumstances. But depending on what kind of sound the developer, what kind of tag the developer associates with the sound, you may or may not get the behavior that you expect. So Its summary. iOS comes with lots of built-in icons, we looked at those. We looked at some of those, we didn't look at all of those. With a lot of built-in functionality, for example, force presses, and sound behavior, different kinds of views. A lot of these things have been standardized. They are developed by looking at common cases in which multiple apps have needed certain kinds of support. And by providing standardized support, Apple has given a higher quality user experience, so the flip side is you should leverage that as well, don't work against it. Don't implement and new sound paradigm, if the sound infrastructure that comes with IOS already works for you. It is important that you learn about the options. No one is going to care very much if you implement something and it is already available and yours comes out bad. They're not going to use your app and you don't really have much of a way, much recourse in that case. So whenever possible use standardized approaches and if you want any more information about this stuff go to the Apple human interface guidelines. There's a little link right there. You can just do a google search for it. And you'll find all the things that I've talked about today and also some additional depth in some of the items if you wanna know more about them. And of course the Apple human interface guidelines are translating from these high level aesthetic design concepts all the way down to the code. Those human interface guidelines sit between the design concepts and the code, but they also provide links to get you all the way down into the development environment if you want to know, okay what's the actual lines of code that I put in my software in order to run sound. All right, thank you, that's all for this lecture. [MUSIC]
