In most cases, yes. Unless the application only makes sense for one orientation, users expect a mobile app to support both. The overwhelming majority of consumer tablet apps support both. Ideally you should leverage the natural advantages of each orientation. On tablets, master-detail presentations work best in landscape; a turn to portrait can then focus just on the details. Most users hold a phone in portrait orientation but appreciate the ability to turn to landscape for easier reading of small text or to watch videos.
Mobile devices cannot exactly duplicate tool tips because they have no ability to detect hovering. Mobile solutions include Touch and Hold to bring up contextual options or help, a Contextual Help mode which displays Coachmarks on tap instead of performing actions, help screens which show all the tool tips at once, etc. A well-designed natural user interface should have less need for tool tips The best approach will depend on the application.
For more information on contextual actions, see Contextual Actions and Overlay pattern.
For list of display gestures, read Display Gestures pattern. For list of device gestures, read Device Gestures pattern. You may also want to see a sample called Gesture Demo that demonstrates how gestures can be implemented and used in MAF applications.
Web-based mobile apps have limited access to gesture support. Complex or obscure gestures should be avoided in any case, because they are hard for users to discover and remember. Oracle does not yet have formal standards for gestures; for now it's best to err on the side of simplicity.
You should not attempt to design a phone or tablet application without regular access to the devices which will actually be used. Designs which seem spacious on a desktop may appear cramped when seen on smaller screens or may actually change appearance or behavior. If you design on a desktop, you should constantly refresh your view from the phone or tablet. It is indeed possible to design directly on a tablet. Tablet-based wireframing and prototyping tools are surprisingly powerful and allow direct, continuous iteration of the design. For more tablet design tips and tricks, see UX Direct website.
Formal and informal testing of phone and tablet apps is also quite feasible and should be done throughout development. User interactions can be captured by fixing the device with a video camera pointing downwards, or by using built-in Airplay functionality and a desktop app like Reflector to capture video while the user holds the device in a natural fashion. For more testing tips and tricks, see UX Direct website.
We find that even when desktop users are your primary audience, there are advantages to a "mobile-first" approach. Designing for a smaller screen and quick on and off interaction style forces you to focus on essentials and distill your app down to what really matters. All users benefit from a more sharply focused design.
Responsive design techniques can greatly improve overall presentation across many screen sizes. But there is more to mobile design than screen layout. Phone and tablet users often have very different use cases and behavior patterns. Activities which work great on a phone may not even make sense for a tablet app. Some components which users expect on tablets aren't available on phones. Multi-step desktop and tablet workflows may need to be broken into smaller steps for a phone. As always, before designing find out who your users are and what they need.
When designing a mobile application, you should pay attention to the following Mobile Design Principles:
For more information on these principles, see this page.
In MAF, there is a set of Data Visualization Tools (DVT) that you can use to create various charts, gauges, and maps to represent data in your MAF AMX application feature. For more information on DVT, read this page on www.oracle.com.
The MAF native client and browser client solutions are Oracle's preferred development methods unless you have a specific business need to use another technology. Developing an application without one of these two solutions must be justified and may require multiple product development approvals. The application platform will impact end users, capabilities, time to market, and maintenance. Understand the specific advantages and disadvantages of each platform before you start designing the application.
A browser-based ADF application runs in a browser on any mobile operating system and is accessed by a URL. Currently, browser applications work only when there is a network connection. ADF mobile applications are built using the open-source Trinidad components, which are based on ADF 10G. Trinidad components are used for mobile development because they have a special render kit for mobile devices whereas ADF Faces rich client framework components currently do not. This render kit allows for lighter footprint and faster download than the current ADF Faces rich client component library. JDeveloper makes it easier to develop because it embeds interface-rendering logic that will automatically format the fit and finish across major mobile browsers such as those found on iPhone, BlackBerry, Symbian, Windows, Android, and WebOS. The mobile client can display charts and graphs, capabilities that are not yet available within the native client. Maintenance and updates require no end-user action.
An ADF native application is installed on a Java-supported device along with a SQLite database and an application file that defines ADF's Model View Controller (MVC) stack. ADF native applications are built with a new set of components that were designed specifically for mobile and require an on-device Java Virtual Machine (JVM). Applications can be deployed directly to end users or by sending a single application package to a technical administrator for management. Once deployed, subsequent application updates will have to be installed on each device. The current version of the native client runs only on Windows Mobile and BlackBerry (future versions will continue to add support for other platforms like Android, Symbian and iPhone). Native applications can leverage contextual menus accessed by dedicated hardware or "soft key" buttons. The end user can work when there is no network connection because the native client framework includes an on-device database. When there is coverage, the native client can sync data with Web services as needed.
ADF native applications allow for tighter integration between the applications on the device, such as calendar and contacts, and the enterprise data. The level of integration, such as two-way syncing between device and enterprise calendars versus one-way syncing, will vary and depends upon the amount of access permitted by the mobile operating system.
The differentiating factors for browser versus native applications are summarized above. If all factors are equal, develop your application for the browser client because it provides more interface capabilities and is easier to develop, deploy, and maintain. Always base your decision on the most important end-user and application requirements which should be derived from mobile use cases.
The most important consideration is, are you working from the same code base for iOS and Android? If you are, you need to plan for showing different views.
Headers have differences - iOS usually puts icons or buttons on either side of a centered Page Header, while Android (i.e. Action Bar) usually puts an App Icon to the left, followed by the left justified Page Header, then a set of icons to the right. So using images or buttons with icons only might be a better solution for single code base.
Apple's iPhone Simulator provided by Apple's Xcode is intended to provide developers an environment to test Apple iOS applications on Apple iPhone, iPhone Retina (HD) and iPad without actually requiring the physical devices themselves. This is the same for Android emulators as well, as you can create emulator of different form factors and resolutions to simulate the devices you want to support.
However, the simulator does have limitations including lack of support for simulating certain device services. Furthermore, Android emulator performance is poor overall, and you will find it time-consuming to rely on Android emulator alone. Giving that, it is recommended testing on both the device simulator and the actual Apple iOS/Android devices on which the application will be deployed.
To develop MAF apps, you need Oracle JDeveloper and Mobile Application Framework Extension. For more information, review this page on www.oracle.com.
You may also be interested in tutorials that get you started developing applications with Oracle MAF.
For information on creating a mobile application, read this tutorial on oracle.com.
See MAF Samples, Community Samples, and Hosted Gallery.
Transparency is good for things like Overlays when you want to educate users about features of your application. On the other hand, dimming the background helps users to focus on content of Popups and Modal Views.
White, Light Gray and Medium Gray are background colors allowed to be used on headers, footer and pages. You can combine them as you want with your application. The default is Light Gray Header and Footer, with a White page.
It is recommended that Photos of people and object be placed in a circular shape. There are two methods to achieve this. First you can download Photoshop mask to apply to your photos. Second you can use e.g. the following CSS and apply it to your square photo.
.avatarPhoto {
width: 50px;
height: 50px;
background-image: url(image.png);
background-size: cover;
border-radius: 50%;
border: 3px solid white;
box-shadow: 0px 0px 1px rgba(0, 0, 0, 0.4);
}
For the current release All Header and Footer icons and buttons should be themed to the Alta Blue color (#0572CE). Additional themes will be investigated for upcoming releases.
See this chapter from the Developer's Guide for more information on skinning MAF browser applications.
There are two themes available in MAF. The new theme is Alta Mobile and is available in MAF v1.1 Patch and MAF 2.0. This theme is styled for both iOS 7 and Android 4. The legacy theme is FusionFX Mobile.
See the Alta Icons Design Guide for more information.
For more information on sizing images for MAF, see this blog post from the Oracle Mobile Platform Blog.
The important thing to understand about pixels vs. points is that higher resolutions mean sharper displays, but do not change the basic nature of the interaction: the ratio of finger size to physical device size. In iOS, moving from lower resolution to retina resolution doubles the pixels, but does not affect the points used to describe the basic layout of the screen. Android is more complex with multiple size groups and multiple DPI groups; display-independent pixels is their equivalent to points.
Grid icons will be more common for iOS and Android. Buttons on Action Sheets are used on iOS. These icons and buttons will be placed in a Popup. On the phone the popup can slide up from the bottom, while on tablets it may animate differently.
Functional icons can be displayed when 1 or 2 actions need to be performed on a list item. When there are more than 2 actions, icons can be revealed by performing a swipe gesture on the list item.
Navigation and page based actions are usually put in the header or footer. These actions take action on all objects on the page or a selected object on the page.
Both Carousels and Film Strips display a collection of related content. Carousels are good for cover flows and square containers. FilmStrips show pagination similar to Android and iOS Home Screens.
In case of the Carousel, the item that appears in the center of the Carousel is the selected/focused one. Users can navigate through the related content by swipe. In case of the FilmStrip, related content is displayed in a grid. Users can swipe through filmstrip pages that are indicated by pagination dots. Both components can be configured to open an item using tap.
This behavior can be used for allowing users to navigate forward and backward between screens. It is similar to what is used in browsers where users can swipe left or right to go forward or backward in history. Do not use this behavior if you want to use the swipe gestures for other functionality, e.g. opening drawer in the Springboard.
The Toolbar component is a container that can be placed in a header and/or footer of the page. It contains actions users need to perform. On the other hand, the Navigation Bar is always displayed at the bottom of the application screen and allows users to switch between tabs (i.e. application features). If the app needs a contextual navigation bar, a footer can be styled to look like a navigation bar.
All of these provide the ability to navigate an app. The Navigation Menu displays a set of navigational items in a list view. There are two common variations: 1. Page Menu, which displays the menu on a home page of phone apps, and 2. Popup Menu, which shows the menu in a popup that is triggered by a button or icon in a header or footer. The Popup Menu is commonly used on tablets. The Navigation Bar is always displayed at the bottom of the application screen and allows users to switch between tabs (application features). The number of visible tabs is limited (varies between 5 to 9). In contrast to the navigation bar, the springboard pushes the page to the right when displayed. When closed, the Springboard is usually hidden. Because the springboard contains a vertical list, it is capable of displaying more features that the navigation bar. Note that it is not recommended to use the navigation menus, navigation bar, and springboard together.
The Button Set is a component that behaves as a toggle or radio button. It is usually used at the top of the page and allows users to switch between views of a feature. On the other hand, the Navigation Bar is always displayed at the bottom of the application screen and allows users to switch between tabs (application features). You can use these components at the same time. For example, the navigation bar can show features of the app (Music, Movies, and Shows) and segmented button can switch between Featured and Charts views
Use the Navigation Menu when you need to switch between application areas and use the Split View when you have an information-based productivity or utility applications where manipulating lists of data is central.
The Grid View allows users to scroll the grid horizontally and/or vertically. Since the Grid View allows for spanning cells and/or rows, it is good for being used for any type of dashboards. On the other hand, dashboard style navigation in Springboard may consist of a number of pages that hold a fixed number of objects. The number of pages is indicated by pagination dots. Users can switch between pages by swiping left or right, vertical scrolling is not recommended. The Springboard is useful e.g. for home screens that contain icons that launch applications upon tap.
The Grid View shows related content in one grid which users can scroll horizontally and/or vertically. On the other hand, Swim Lanes consist of rows and columns, where rows identify related content and columns hold items of that content. To navigate over items in each lane, users can scroll the lanes horizontally. To navigate between related content, users can scroll the lanes vertically. Grid Views can be implemented with Iterators and TableLayouts, while Swim Lanes are implemented with panelGroupLayouts, filmStrips and carousels.
If users have access to a button, but that button is currently unavailable, disable it. If users do not have access to that button, do not disable it, but hide instead.
The Button and Link behavior is similar. These components usually perform an action event. Button labels are generic, such as Submit, Create, or Edit. On the other hand, the Link usually consists of a specific object name, such as Joe Doe. Also you can wrap a link around an icon or image.
Use the Split View if you have an information-based productivity or utility applications where manipulating lists of data is central (e.g. e-mail client where the navigation pane shows list of emails and the detail pane shows content of selected email). Note that it is not recommended to use the Split View on phones so you may want to consider using the Navigation Menu instead.
Use the Drawer when you want to allow users to navigate between different application features. When displayed, the springboard pushes the page to the right. When closed, the springboard is usually hidden. The Springboard is common on phones and tablets.
Both components can be used for simple "Yes" and "No" or "On" and "Off" choices.
Use the Radio Set for selecting a single item from mutually exclusive choices (minimum is two choices). Do not use it for simple "Yes" and "No" choices, use the Switch or Checkbox instead. If you provide users with more than three choices, the screen may get crowded and you may want to use the Select instead. Also sometimes on Mobile the user drills-down to a new page or popup to make a selection on a Radio Button List.
Use the Checkbox for simple "Yes" and "No" or "On" and "Off" choices. On the other hand, use the Checkbox Set for selecting multiple choices from a list. If you provide users with more than three choices, the screen may get crowded and you may want to use the Choice instead. Also sometimes on Mobile the user drills-down to a new page or popup to make a selection on a Radio Button List.
Use the Choice for selecting a single item from mutually exclusive choices. On the other hand, the Select Many allows users to select multiple items from given choices. If you provide users with less than three choices, you may want to consider using the Radio Set as an opposite to the Choice and the Checkbox Set as an opposite to the Choice Many.
Use the Radio Set for selecting a single item from mutually exclusive choices (minimum is two choices). Do not use it for simple "Yes" and "No" choices, use the Switch or Checkbox instead. On the other hand, use the Checkbox Set for selecting multiple choices from a list. If you provide users with more than three choices, the screen may get crowded and you may want to consider using the Select Many instead.
Use the Choice to allow users to select a single item from mutually exclusive choices. On the other hand, use the Checkbox Set to allow users to select one or more items from a set of choices. Also sometimes on Mobile the user drills-down to a new page or popup to make a selection on these components.
Both components are used for selecting multiple items from given list. If you provide users with more than three choices, the screen may get crowded and you may want to consider using the Select Many instead of the Checkbox Set.
Icons are used with image component and might be wrapped in a link to perform an action. Buttons have the action event and icon state information built in.
Normal buttons are usually used in headers and footer, but maybe used in other locations. Small buttons are NOT used in headers or footer, but maybe used on the page. Large buttons should be used cautiously on the page, when there is a single action that needs to be performed. Action Sheet buttons are used to make contextual selections.