Common Design Patterns


So we just recapped different
layout managers and looked at how you’d use various layouts
together to create some example screens. As you probably noticed we started using
these circles and buttons and toolbars. Let’s start diving a little deeper into
what some of those elements were and why they keep appearing
all over the place. Now each application is
an individual snowflake with different content and goals. Just because they’re unique though, it
doesn’t mean that we should force users to learn new conventions
to operate them. By following some established
patterns of the platform, you can accelerate your users understanding
of the app, making it feel intuitive. Imagine if every model of car had
a different layout of the pedals, the steering wheel and the levers. While you might be able to
learn one model you’d have a hard time moving to another. Your UI is exactly the same. By following some conventions users
can quickly get in and drive your app. Here is some of the most
prevalent patterns used on Android to organize your interface and
navigate around it. A Toolbar is a horizontal bar, which provides a standard way to
present titles and actions in your lab. It’s made up of a navigation
area on the left, a title area, and the menu of actions. It’s a very flexible widget, and
each of these function is optional. A nice feature is that the toolbar can
show actions either directly within the tool bar, or they can be collapsed
under a sub menu known as an overflow if there isn’t enough room. And it will base it’s decision
on whether there’s enough room to show everything. Tapping the overflow item itself yields
this overflow menu of additional actions you can take. The toolbar itself is a view group,
so you can add children to it. For example,
I could add a Spinner Control as a child view to provide some
kind of navigational control. Now, toolbars are used
extensively in Android. So they’re very recognizable to your
users, and a common place to look for actions or present them. They generally use a standard
height which varies by screen size, and can be queried using
the actionBarSize Free match P. They’re also a great place
to embed your brand’s color. Next, the App bar. The app bar is just
a special case of a toolbar, where it’s placed at
the very top of the screen. As such, the title field often
provides a screen title. And the navigation icon provides access
to screen level navigation options. The app bar often uses an extended
height to provide more space for branding or to contain a header image. In this case it’s using multiples
of the standard height. Next up Tabs. Tabs let you organize and navigate to different sections
within your screen or app. On Android, tabs always appear
at the top of the screen. And you can switch between them
using a horizontal swipe gesture. Generally, they sit on the same surface
as your app bar, if you’re using one. Now, tabs can be a great way to
provide the main way of navigating about your app. Or providing sub-navigation if
you’re using a different top-level navigation construct. Such as a Navigation Drawer. Now a Navigation Drawer is a panel
that slides in from the left of the screen and it contains
the top level navigation options to different parts of your application. The drawer itself can be
divided into sections and frequently provides access to account
information here in this top area. Now, the drawer is closely associated
with the so-called hamburger icon. This three-line icon in your toolbar. Either pressing this or dragging from the left edge of
your device will open the drawer. The drawer can work well if you
have a number of different sections that you want to provide
quick navigation to without taking up persistent
space on every screen. However, if you don’t need this, say if
you only have a few sections to navigate between, then a different pattern,
like tabs might be more relevant as they’re
going to be more obvious to your users. It’s also important to use restraint and thoughtfully select items to
put in the navigation drawer. It shouldn’t become a dumping ground for
all the things. Android also has pretty common
patterns around Scrolling and Paging. Users are typically comfortable
with scrolling vertically to see more information on the screen. Horizontal scrolling is less common,
especially with text content, as it can be frustrating to read. More common is to use a horizontal
gesture to page through content. So, each gesture takes you to one
screen page, back or forward. So for example,
if you’re reading emails or news stories,
then it’s a very useful pattern. Horizontal Paging is especially common
for a details view launched from a list, where you have a mental model of what
the next page of items might be. Note, that as we just
covered in the tab section, horizontal swipes should
change pages between tabs. So the effort is kind of
incompatible to use both tabs and horizontally paid content. Another extremely common pattern
on Android is List to Details, where you would show a list
of individual items and clicking on one would take you
to a subsequent detail screen. You’ve probably used this 100 times. Such as viewing your contacts or
reading news stories for example. A variation on this pattern
is to show both the list and detail sections on the same
screen on larger devices. So here these two screen would be
separate on a small device and brought together on a larger device. Showing just a list on a large
screen can look awkward and leave a lot of empty space. Additionally, showing both items at once
can allow you to obtain more context about the activity you’re performing and
prevents what we call Pogosticking. Where the user is forced to go
into details and back up, and into a details and back up. We’ll go into much more
detail on other patents for larger screens in lesson five. Now it’s absolutely okay to
deviate from these patents if and when it makes sense for
your specific use case. These are patents after all,
not strict rules. But make sure you’re doing so for good reasons, as you’ll be asking your
users to learn a bespoke interaction. The phrase I like to use here
is deviate with purpose. Picking an application’s structure and navigation scheme depends on
the content in your application. A good exercise is to sketch out
an Entity Relationship Diagram. This shows the objects
in your application and how they relate to each other. Once you understand this, you can pick
an application structure to match.

Tags:, ,

2 Comments

Add a Comment

Your email address will not be published. Required fields are marked *