‭Chapter 3 : Mobile Design Principles‬

‭●‬ ‭Concept of Mobility‬

‭○‬ ‭Mobility extends beyond‬‭hardware‬‭and‬‭communication‬‭to‬‭software‬
‭implementation‬‭and‬‭user experience‬‭.‬
‭●‬ ‭Mobilizing Application‬
‭○‬ ‭Developers and designers often‬‭mistakenly treat mobile applications‬‭as a‬‭subset‬
‭of web or desktop applications‬‭.‬
‭○‬ ‭Emphasizes the importance of mobilizing instead of miniaturizing.‬
‭●‬ ‭The Carry Principle‬
‭○‬ ‭Encourages considering‬‭mobile device characteristics‬‭and‬‭unique environment.‬
‭○‬ ‭Stresses the‬‭need to target mobile user needs‬‭specifically.‬
‭●‬ ‭Components of Mobile Applications‬
‭○‬ ‭Miniaturization involves‬‭shrinking the web UI to a mobile screen‬‭without‬
‭considering mobile device characteristics.‬
‭○‬ ‭Miniaturization‬‭doesn't leverage mobile platform features‬‭and combines web‬
‭application‬‭drawbacks‬‭with mobile device‬‭weaknesses‬‭.‬
‭○‬ ‭Mobilization precisely targets mobile user needs, making optimal use of‬
‭technology.‬
‭●‬ ‭Mobilizing vs Miniaturization‬
‭○‬ ‭Miniaturization treats the mobile environment as a‬‭subset of the desktop‬
‭environment‬‭.‬
‭○‬ ‭Mobilization focuses on‬‭mobile user needs‬‭and‬‭utilizes technology‬‭effectively.‬
‭●‬ ‭Advantages of Mobilizing:‬
‭○‬ ‭Takes into account mobile platform‬‭features not present in web‬‭or desktop‬
‭applications.‬
‭■‬ ‭Multitouch and touch‬‭gestures‬
‭■‬ ‭One-handed operation‬‭feature‬
‭■‬ ‭Sociability‬‭features‬
‭■‬ ‭Location-awareness & Context awareness‬
‭■‬ ‭Access to mobile device‬‭hardware sensors‬
‭●‬ ‭Example Illustration:‬
‭○‬ ‭Miniaturizing a web application may‬‭overlook the advantages of mobile features‬
‭like the camera, GPS sensor, and connectivity.‬
‭○‬ ‭In the context of an AirAsia application:‬
‭○‬ ‭Camera‬‭: Scan QR code for various functionalities.‬
‭○‬ ‭GPS sensor‬‭: Detect nearest airport, provide suggestions, and map shortest‬
‭route.‬
‭○‬ ‭Remote connectivity‬‭: Perform remote check-in via set QR code.‬
‭●‬ ‭Mobilization Encourages:‬
‭○‬ ‭Use of mobile device‬‭facilities and sensors to enhance usability‬‭.‬
‭○‬ ‭Leveraging camera, GPS, and connectivity for‬‭improved user experience‬‭.‬
‭●‬ ‭Usability Improvement:‬
‭○‬ ‭Users‬‭benefit from features‬‭like barcode scanning via phone camera, eliminating‬
‭the need for manual data entry.‬
‭●‬ ‭Tips to Avoid Miniaturization:‬
‭○‬ ‭Avoid Excessive Textfields:‬
 ‭■‬ ‭Mobile users‬‭lack time to fill in extensive details‬‭in Textfields.‬
‭■‬ ‭Rely on social logins‬‭(e.g., Google+ or Facebook) to obtain information‬
‭efficiently.‬
‭■‬ ‭Save or cache user data‬‭to prevent repetitive Textfield filling‬‭.‬
‭■‬ ‭Excessive Textfield inputs discourage mobile application usage.‬
‭●‬ ‭Point to Ponder:‬
‭○‬ ‭Reflect on the apps‬‭on your mobile phone.‬
‭○‬ ‭Notice if any application‬‭contains more than three Textfields‬‭simultaneously.‬
‭○‬ ‭Users‬‭shouldn't fill in multiple details‬‭(e.g., Name, Student ID, Identity card‬
‭number, email) simultaneously on a mobile app.‬
‭○‬ ‭Retrieve non-essential particulars from a server‬‭to minimize manual Textfield‬
‭entries.‬
‭●‬ ‭How to Avoid Excessive Textfields‬‭:‬
‭○‬ ‭Present information in an‬‭easily accessible and selectable manner‬‭for mobile‬
‭users.‬
‭○‬ ‭Consider formats like‬‭objective questions or True/False‬‭to simplify user‬
‭interaction.‬
‭○‬ ‭Analogous to answering examination questions efficiently.‬

‭●‬ ‭Use Mobile Facility to Guess User Details:‬

‭○‬ ‭Inferred input fields from mobile apps‬‭, e.g., GPS for country/state, language from‬
‭phone settings, and email through social logins.‬
 ‭○‬ ‭Users shouldn't input every detail‬‭; mobilize applications to auto-detect user‬
‭details.‬
‭●‬ ‭Display Hints in TextFields:‬
‭○‬ ‭Enhance user experience‬‭by providing hints in TextFields.‬
‭●‬ ‭Split Long Entry Forms:‬
‭○‬ ‭Splitting forms into multiple screens‬‭improves user attention span.‬
‭○‬ ‭Users click "Next" for each data entry, simplifying the process.‬
‭●‬ ‭Mobilizing Apps:‬
‭○‬ ‭Mobilized applications‬‭auto-detect user details‬‭from recorded information.‬
‭○‬ ‭Retrieve username, name, and profile photos‬‭automatically.‬
‭○‬ ‭Utilize device sensors, calendar, and location‬‭for seamless data input.‬
‭●‬ ‭The Carry Principle Implication on Device:‬
‭○‬ ‭Form-factor must be smal‬‭l for portability.‬
‭○‬ ‭Features integrated‬‭for ease of use.‬
‭○‬ ‭UI adapts to small screens,‬‭promoting single-window display‬‭.‬
‭●‬ ‭User Availability:‬
‭○‬ ‭Mobile users are‬‭more available for communication‬‭due to device portability.‬
‭○‬ ‭Sustained‬‭focus may be limited‬‭, and social behavior is modified.‬
‭●‬ ‭Native vs. Web-Based App:‬
‭○‬ ‭Mobile Web Application:‬
‭■‬ ‭Easiest‬‭to learn and‬‭cheapest‬‭to produce.‬
‭■‬ ‭Depends on the‬‭internet and W3C standards‬‭.‬
‭■‬ ‭Platform-neutral but‬‭lacks access to device hardware features.‬
‭○‬ ‭Native Application:‬
‭■‬ ‭Steeper‬‭learning curve,‬‭tied to a specific mobile platform‬‭.‬
‭■‬ ‭May use the internet but‬‭doesn't depend‬‭on it.‬
‭■‬ ‭Access to device‬‭hardware features and sensors‬‭.‬
‭●‬ ‭Advantages of Web-Based App:‬
‭○‬ ‭Portable‬‭, needs only‬‭internet connection‬‭and‬‭mobile browsers‬‭.‬
‭○‬ ‭Uses open W3C Web API,‬‭not tied to a single mobile platform‬‭.‬
‭●‬ ‭Advantages of Native App‬‭:‬
‭○‬ ‭Fast and uses Native API‬‭, tightly integrated with the mobile platform.‬
‭○‬ ‭Supports‬‭offline use and accesses‬‭hardware sensors and features.‬
‭○‬ ‭Generally‬‭superior to mobile web applications‬‭.‬
‭●‬ ‭When to Make a Mobile Web App:‬
‭○‬ ‭Launching an app on a‬‭new platform with a small user base‬‭.‬
‭○‬ ‭Providing a fallback option‬‭for users without native apps.‬
‭○‬ ‭Focusing on application‬‭services and connectivity‬‭, independent of the mobile‬
‭device platform.‬
‭●‬ ‭Mobile Hybrid Web App:‬
‭○‬ ‭Derived from heterogeneous sources, written with web technology but‬‭runs in a‬
‭native app container.‬
‭○‬ ‭Accesses native mobile platform‬‭features.‬
‭○‬ ‭Portable in source code form‬‭, compiled for different mobile platforms.‬
‭●‬ ‭Examples of Hybrid Mobile Frameworks:‬
‭○‬ ‭Ionic: Ionic Framework‬
‭○‬ ‭Phonegap/Cordova: Phonegap‬

‭●‬ ‭Mobile UI and Design Patterns:‬

‭○‬ ‭UI Design Patterns:‬
‭■‬ ‭Good solutions‬‭to standard UI design problems.‬
‭■‬ ‭Provide a‬‭starting point‬‭for specific application parts.‬
‭■‬ ‭Encode user expectations‬‭, violating which can negatively impact the user‬
‭experience.‬
‭○‬ ‭Elements of Mobile UI Design:‬
‭■‬ ‭Screen Design‬‭:‬
‭●‬ ‭List-based Layout‬
‭●‬ ‭Grid-Based Layout‬
‭●‬ ‭Application Navigation‬
‭●‬ ‭Tab Navigation‬
‭●‬ ‭ViewPager Navigation‬
‭●‬ ‭Navigation Drawer‬
‭●‬ ‭Dropdown Navigation‬
‭■‬ ‭List-based Layout‬‭:‬
‭●‬ ‭Common screen for displaying a lot of data efficiently.‬
‭●‬ ‭Vertical orientation suits mobile screens.‬
‭●‬ ‭Natural scrolling for users.‬
‭■‬ ‭Grid-Based Layout‬‭:‬
 ‭●‬ ‭Alternative to standard list-views.‬
‭●‬ ‭Suited for data sets represented through images or icons.‬
‭●‬ ‭Captures user attention effectively.‬
‭■‬ ‭App Navigation - Tab‬‭:‬
‭●‬ ‭Facilitates exploration and switching between views.‬
‭●‬ ‭Used for browsing categorized data sets.‬
‭●‬ ‭Can be scrollable or fixed.‬
‭■‬ ‭View Pager Navigation‬‭:‬
‭●‬ ‭Similar to tab navigation but without labeled tabs.‬
‭●‬ ‭Relies on navigation indicators (circles or dots).‬
‭●‬ ‭Allows easy exploration and switching between views with finger‬
‭swipes.‬
‭■‬ ‭App Navigation - Navigation Drawer‬‭:‬
‭●‬ ‭Panel displaying main navigation options on the left edge.‬
‭●‬ ‭Hidden most of the time, revealed with a left-edge swipe.‬
‭●‬ ‭Provides quick navigation without consuming screen space.‬
‭■‬ ‭App Navigation - Dropdown‬‭:‬
‭●‬ ‭Useful when changing content is important but not frequent.‬
‭●‬ ‭Preferred for more frequent content switching.‬
‭●‬ ‭Occupies a small area on the toolbar/action bar.‬
‭●‬ ‭Mobile UI Design Patterns:‬
‭○‬ ‭Document known‬‭solutions to common design problems‬‭.‬
‭○‬ ‭Encode as user expectations‬‭; violating them can impact user experience.‬
‭●‬ ‭Mobile UI Design Principles‬
‭○‬ ‭Mobile apps should be‬‭user-centric to be useful‬‭.‬
‭○‬ ‭People must be‬‭able to recognize what is the purpose of the interface‬‭you’ve‬
‭designed and how to use it.‬
‭○‬ ‭Put only one‬‭primary action per screen‬
‭○‬ ‭example : Uber - goal of user use uber is to take cab, the application does not‬
‭burden users with other information. The only information that been display is‬
‭Map information and user action is only to select a pickup location in a single‬
‭screen.‬
‭●‬ ‭Make Navigation Self-Evident‬
‭○‬ ‭Mobile navigation must be‬‭coherent, consistent‬‭for the app and communicate the‬
‭current location.‬
‭●‬ ‭Design Finger-friendly Tap-targets‬
‭○‬ ‭It's important to make your targets‬‭big enough‬‭so that they’re easy for people to‬
‭tap.‬
‭○‬ ‭Edges of the target are visible when the user taps it. Provide user with clear‬
‭visual feedback that they hit the target accurately.‬

‭●‬ ‭Text Content Should be Legible‬

‭○‬ ‭It’s‬‭challenging to fit a lot of information‬‭on a small UI.‬
‭○‬ ‭Text should be at least‬‭11 points, able to read at a normal viewing distance‬
‭without zooming.‬
‭●‬ ‭Make Interface Elements Clearly Visible‬
‭○‬ ‭Use‬‭color and contrast‬‭to help users see content.‬
‭○‬ ‭Choose‬‭primary, secondary and accent color‬‭that support usability‬
‭○‬ ‭Ensure‬‭sufficient color between elements‬
‭○‬ ‭Make sure there is‬‭enough contrast between the backdrop and the font color‬
‭●‬ ‭Minimize Need For Typing‬
‭○‬ ‭Minimize the amount of typing required to use apps.‬
‭○‬ ‭Keep‬‭forms short and simple‬‭by removing any unnecessary fields.‬

‭●‬ ‭Element of Mobile UI Design for using‬

‭○‬ ‭List-based Layout‬‭:-‬
‭■‬ ‭List more natural to be use as user‬‭can scroll down to search‬‭and view‬
‭data without much efforts.‬
‭○‬ ‭Grid-Based LayScreen design‬
‭■‬ ‭List-based Layout‬
‭○‬ ‭Rationale Out‬
 ‭■‬ ‭Suited for‬‭show data set‬‭represent through images/icons‬
‭■‬ ‭Images/icon‬‭caught user attention effectively‬
‭■‬ ‭Can convey‬‭more meaning in images‬
‭●‬ ‭Application Navigation‬
‭○‬ ‭Tab Navigation‬
‭■‬ ‭Easy for user to‬‭explore & switch‬‭between views‬
‭■‬ ‭Use to‬‭browse categorized dataset‬
‭■‬ ‭Can be‬‭scrollable/fixed‬
‭■‬ ‭Enable user to‬‭quickly navigate‬‭between different part of application‬
‭○‬ ‭View Pager Navigation‬
‭■‬ ‭Relies on‬‭navigation indicator‬
‭■‬ ‭Easy for user to‬‭explore & switch‬‭between views/functional of application‬
‭with finger swipe‬
‭○‬ ‭Navigation Drawer‬
‭■‬ ‭Panel that displays the app‬‭main navigation options‬
‭■‬ ‭Hidden but appear‬‭when user swipe finger to the left edge of screen‬
‭■‬ ‭Does‬‭not consume spaces‬
‭■‬ ‭Provide‬‭quick way for user to navigate from one view to another‬‭without‬
‭press “Back” button‬
‭○‬ ‭Dropdown Navigation‬
‭■‬ ‭Do not change with rest of screen‬‭, thus provide user with anchor point to‬
‭switch content.‬
‭■‬ ‭Occupies small area on the toolbar/action bar on application‬

‭●‬ ‭Standards screen sizes for mobile devices‬

‭○‬
‭●‬ ‭Phablet‬
‭○‬ ‭Made up of two words‬‭(phone+tablet)‬
‭○‬ ‭Contains functions of tablets‬‭like touchscreen, virtual keyboards, mobile‬
‭operating system, camera, app storage.‬
‭● ‭Why different screen sizes
‭○ ‭Even size are same, device also‬‭have different screen densities
‭○ ‭Measure in‬‭“dots per inch”(dpi)
‭● ‭Challenges in supporting multiple screen sizes
‭○ ‭Need to identify‬‭most common users target phone screen sizes/density‬‭(different
‭for each application)
‭○ ‭Need to‬‭target widest audience‬‭, while not exclude user use larger/smaller
‭devices
‭● ‭Size, Density and Resolution
‭○ ‭Screen size - amount of‬‭physical space available‬‭for display an interface, (inch)
‭○ ‭Screen density - amount of‬‭pixels appear within constant area of display‬‭,‬‭pixel
‭per inch (ppi)
‭○ ‭Screen resolution - amount of‬‭pixels available in the display‬‭,‬‭scale-independent
‭pixel (sp)
‭● ‭Screen sizes and densities
‭○ ‭Some device has‬‭same screen size but different screen densities
‭○ ‭Mobile device has large variation of dpi compare to screen size
‭○ ‭HTC One Max (5.9”) has 373 dpi / Google Nexus 6 (5.9”) has 493 dpi
‭● ‭Density Independence
‭○ ‭Achieve when app‬‭preserves the physical size of UIelements‬‭when display on
‭screen with different densities
‭○ ‭Important to‬‭prevent UI element form appears larger on low-density screen‬‭and
‭smaller on high-density screen.
‭● ‭DPI and PPI
‭○ ‭PPI
‭■ ‭Number of‬‭pixels contain in one inch of image
‭○ ‭DPI
‭■ ‭Number of‬‭printed dots contain in one inch of image
‭● ‭Calculating Screen Sizes/Resolution/DPI
‭○ ‭Calculate DPI
‭■ ‭Diagonal Screen size (D) : 6 inch, Resolution: 2560*1440
‭1. ‭Calculate screen aspect ratio, from resolution, using greatest common
‭denominator(GCD)
‭2560x1440, GCD of 2560 and 1440 is 160
 ‭So, 2560/160 = 16, 1440/160 = 9. Thus the screen ratio of 2560x1440 is 16:9‬
‭2. ‭Calculate screen height and length
‭d² = L² + W² , screen ratio 16:9
‭d² = 16² + 9²
‭d² = 256+ 81
‭d² = 337, d = 18.35
Screen Size = measured diagonally form one
‭D’ = d / D corner to opposite corner
‭= 18.35/6”
resolution = number of pixels on the screen
‭= 3.06 = 1920x1080, 1920 wide 1080 high
= width x height

‭L’ = L/3.06‬ DPI = (wide^2 + high^2) / Screen Size

‭= 16/3.06‬ = (1920^2+1080^2) / 15 inch
= 323520
‭= 5.23”‬
‭W’ = W/3.06‬ SA Ratio = 16:9 / 4:3
‭W’ = 9/3.06‬
Screen Length = Aspect Ratio x Height
‭W’ = 2.94”‬
Screen Height = screen size / sqrt (1+(aspect ratio)^2)

‭Screen length = 5.23”‬

‭Screen Width = 2.94”‬
‭3. ‭Get Screen Resolution, r =2560x1440
‭rl = 2560, rw = 1440
‭DPI = rl / L’ = 2560 / 5.23 = 489 (round to nearest int)
‭DPI = rw / W’ = 1440 / 2.94 = 489 (round to nearest int)

‭Thus the DPI for Device X is 489 ± 1‬

‭● ‭Designing for Multiple Screen Strategies

‭○‬
‭○‬ ‭1nd Strategy‬‭: Design app for most common DPI/Screen sizes‬
‭■‬ ‭Do survey to determine most common DPI‬‭&‬‭screen sizes‬
‭■‬ ‭Optimizing the application‬‭for most common DPI & screen sizes‬
‭■‬ ‭Advantage:‬
‭●‬ ‭Faster development‬‭and prototyping‬
‭●‬ ‭Easiest to follow‬‭, not waste time‬
‭●‬ ‭Only‬‭target majority user device‬
‭■‬ ‭Weakness:‬
‭●‬ ‭User‬‭not in target device group find application poorly display‬
‭●‬ ‭Poor user‬‭perception‬‭and‬‭experience‬
‭●‬ ‭Application look‬‭amateurish‬‭&‬‭poorly design‬
‭○‬ ‭2nd Strategy‬‭: Restricting app only for certain DPI/Screen Sizes‬
‭■‬ ‭Add other enforcement‬‭which prevent it to execute in device that has‬
‭lower DPI‬
‭■‬ ‭User with lower DPI devices will‬‭not be able to run application‬
‭■‬ ‭Advantage:‬
‭●‬ ‭Faster development‬‭and prototyping‬
‭●‬ ‭Only target majority user device‬
‭■‬ ‭Weakness:‬
‭●‬ ‭Limited audience‬
‭○‬ ‭3rd Strategy‬‭: Including multiple graphic assets for different screen sizes/DPI‬
‭■‬ ‭Design single application, but‬‭add multiple graphic asset and layout‬
‭■‬ ‭Developer‬‭need to create different graphic asset for different screen‬
‭densities(DPI)‬
 ‭■‬ ‭Create‬‭several graphics with different sizes‬‭to support different screen‬
‭densities.‬
‭■‬ ‭Android categorizes screen densities in several overlapping group:‬
‭●‬ ‭ldpi‬‭= 120 dpi or less‬
‭●‬ ‭mdpi‬‭= between 120-200 dpi‬
‭●‬ ‭hdpi = between 200 – 300 dpi‬
‭●‬ ‭xhdpi‬‭= between 300-400 dpi‬
‭●‬ ‭xxhdpi‬‭= more than 400 dpi‬
‭■‬ ‭Advantage:‬
‭●‬ ‭Develop‬‭single application for multiple device‬
‭●‬ ‭Support‬‭widest user’s device‬‭as possible‬
‭■‬ ‭Disadvantage:‬
‭●‬ ‭Time consuming‬
‭●‬ ‭Have to‬‭create graphic assets to cater uncommon device‬
‭○‬ ‭4th Strategy‬‭: Accommodating screen sizes programmatically different‬
‭■‬ ‭Developer uses percentages‬‭to describe device layout‬
‭■‬ ‭Use by‬‭Mobile Web Application‬
‭■‬ ‭Use‬‭Scalable Vector Graphic (SVG)‬‭to‬‭scale graphics assets‬
‭programmatically‬‭without sacrificing quality.‬
‭■‬ ‭Advantage:‬
‭●‬ ‭Develop single application‬‭for multiple device‬
‭●‬ ‭Support widest user’s device‬‭as possible‬
‭■‬ ‭Disadvantage:‬
‭●‬ ‭Usually‬‭only supported in Mobile Web Application‬
‭●‬ ‭Have‬‭to create graphic assets to cater uncommon device‬
‭●‬ ‭HTML5 Viewport‬
‭○‬ ‭method to let mobile web designers take control over the viewport, through the‬
‭<meta> tag.‬
‭○‬ ‭Viewport: user's visible area of a web page‬
‭○‬ ‭Applying a viewport is the first and most important step to make web pages‬
‭presentable on mobile browsers.‬
‭○‬