Welcome to the first chapter of the course!
So, where do we start?
A starting point of any app development process is the requirements! As developers, it's our responsibility to transform those into beautiful code!
Getting started with the requirements
In your career you'll be developing applications based on initial requirements that will come in different forms and shapes. Some will have complete visual illustrations, detailed descriptions, and precise aesthetic specifications. Some will be sketches on a napkin. Others will be somewhere in between.
Here are the key components of typical app requirements:
Mock-ups - a set of visual screens.
Flow diagrams - diagrams of visuals demonstrating transitions from one appearance to another. Or, ideally, interactive prototypes.
Written descriptions - descriptions that accompany the mock-ups and flow diagrams, clarifications of flows, as well as use cases and scenarios.
Style guides - specific aesthetic requirements.
Let's review each of these in more detail to develop a general idea of what to expect.
Mock-ups are visual representations of the app screens, and they come in two flavors:
High fidelity - screen views which demonstrate the exact visuals to be used in the production (e.g. images, colors, sizes, layout, copy, etc.)
Low fidelity - screen views that demonstrate approximate visuals that will have to be adjusted as the designs get implemented. They typically contain image placeholders, outlines of UI elements, sample copy, and approximate sizes.
You may be presented with exported images (png, jpeg, etc.) as well as the original source files. In either case, you'll be able to extract all the information needed to incorporate the images into the app.
Here are examples of what each of them may look like:
Both types can have various levels of detail.
It's ideal to have the most detailed mock-ups, but it's not aways possible. This is due, in part, to uncertainty when the apps is being design. Additionally, some aspects like gestures, transitions and animations are not possible to communicate using just images. This is why there are typically complimentary materials such as flow diagrams and written descriptions.
Flow diagrams demonstrate the transitions between screens, or parts of a screen. Depending on the size of the project, they may either contain all the possible connections and transitions or just the key ones.
Here's an example of a flow diagram:
Flow diagrams are often accompanied by written descriptions.
Written descriptions are the linking elements for all the visual components. It clarifies and expands the requirements. They may consist of the following elements:
Clarification of mock-ups
Explanation of animations and transitions
Clarification of flows (for example, describing conditions of flow paths)
User stories and Scenarios
Style guides are the aesthetic components of the requirements. They specify colors, fonts, font sizes, use of branding elements (names and logos), layouts, spacing etc.
Here's an example:
Interdisciplinary team collaboration
Where would those requirements come from?
These documents will be produced by various teams participating in the project. This will be done in part as a result of collaboration with development team members (for example, a software architect, team lead, and developers). This collaboration is beneficial on many levels because it:
serves as an opportunity to communicate the technical possibilities to other teams
presents new, interesting challenges to the tech team in the form of a desired design requirement
Ensures that the most suitable and reasonable solution is chosen
Allows for setting realistic deadlines and managing expectations for non-tech teams
So, who are those i-n-t-e-r-d-i-s-c-i-p-l-i-n-a-r-y teams?
In fast-paced, ever-changing work environments, many people wear different hats, take on multiple roles, and are responsible for various deliverables. On top of that, workflows will cover multiple disciplines. You'll get to work with:
UI/UX designers, Interaction Designers, and Product designers
Product and Project managers
Other collaboration groups (they typically don't provide the direct requirements):
Marketing and sales representatives
Also founders, and other fun people!
You may come across some roadblocks. What happens IF? Here are the MOST common issues:
Something is NOT clear in the documents - To overcome this, you can clarify it with the person you received the requirements from. If they can't help, they'll certainly be able to direct you to someone who will.
You have a suggestion regarding any aspect - See the answer to challenge #1
Exciting, isn't it?
Let's see what we have to deal with!
Introducing the project!
In this course we will develop an iOS app based on high fidelity mock-ups. They demonstrate explicitly the appearance of visual elements, layout, and style requirements. We also have some assets provided such as icons, fonts and colors that we’ll have to incorporate in our implementation.
The app we’ll work on is called FrameIT. It will allow you to transform and decorate an image and share your creation!
When the app launches, the user will be presented with a launch screen, which will be replaced by the main screen once the application has loaded.
The main screen will incorporate the following elements:
Framed image panel
Color label & color picker
The framed image panel will consist of 3 elements:
Colored frame - a non-interactive element that will reflect frame color settings as defined by the user.
Placeholder or selected image - an interactive element will support the following gestures:
tap - will allow for choosing an image by displaying the image picker view.
zoom in/out - will resize image.
touch and move - will move image.
rotate - will rotate image.
Start over button - resets settings to the default state - image placeholder and default settings saved at the last sharing.
Color picker will present a panel with 5 colors to choose from. Tapping on a color element will apply it to the image frame and update the Color label. It must be enabled for both states of the image panel (placeholder and selected image). Color label will reflect the changes made via color selection and will display the name of the color below the image frame. Here are the colors to use:
The share button will launch a system sharing capability to which we'll supply a framed image.
Once an image has been shared, the settings of the frame color will be stored to be used as a default parameter the next time the app launches. The user can also reset the settings using the Start over button.
These images will be used within an app if the user selects the option "Random":
Create an Xcode project
We have most of the project defined, that's certainly enough to begin our workflow and create an Xcode project!
You already know how to do it, however, here's a brief summary:
1. Open Xcode and choose Create a new Xcode Project:
2. Choose Single View App template to create a single view application:
3. Provide the initial configuration for your project:
For the Organization Name, you can use your personal name and for the Organization Identifier, you can adopt the following convention: domain-name.backwards.
Make sure Swift language is selected and have the rest of the options unchecked for this project.
4. Choose the location where you want to save your project:
Here you are presented with the project window that displays the app configuration screen:
Let's leave most of the parameters as they are. We'll just set the version number to 1.0 (this is the number that appears in the app store) and the build number to 1.0.1 (this number is used for development purposes).
Where do the Version and Build numbers come from? I recommend following formats:
Version format: two sets of numbers separated by a dot, like
X.X . Let's start with
1.0. Improvements and fixes result in the second number increasing:
1.1, 1.2 , etc. Major modifications result in the first number increasing:
2.0, 3.0 , etc.
Build format: sets of numbers separated by dots like
X.X.X . The first two will always match the corresponding version, and the last one will increase when a build is made (typically for test purposes, whether it's a QA department, user testing, etc.). Now you see where
1.0.1 comes from. This will continue to
1.0.2, 1.0.3 etc.
This helps to quickly identify the range of a development timespan by just glancing at the numbers for both versions and builds.
We are now all set to start developing our app!
The app requirements consist of the following:
High- and low-fidelity mock-ups
and Style guides.
Software development is a collaborative process and developers often work with members of other teams, such as:
Interaction Designers and Product designers,
Product and Project managers,
and Business analysts.
When requirements are not clear or there's a potential problem, it's the developer's responsibility to clarify the requirements and propose solutions to a problem.