Using Sketch and Framer to Create Responsive Mobile Prototypes for Remote Testing: Part 2

In my previous post, I shared my comprehensive workflow for creating native mobile prototypes in Framer that responsively scale across devices with resolution ratios of ~1.778. Please read that post first, as this one will utilize 99% of its workflow. Building upon that workflow, here I am showing my solution for the two problems I experienced testing prototypes on Android devices. Many of the solutions I came up with in this workflow can also be applied to other platforms besides Android.

The need for these solutions comes from the success criteria I set for this project previously:

1. The ability to reuse some code from the desktop prototypes, and in this case, iOS prototypes.
2. Be responsive across multiple mobile devices.
3. Solve the problems my team has been experiencing: Multiple Resolutions, Native Nuances, and Sharing With Remote Testers.
4. Have a gentle learning curve for those with little to no coding experience.

This post mainly addresses solutions for creating the correct native nuances on Android.

My Android Problems

Problem 1

Swap the iOS status bar out for an Android one, and show an Android bottom navigation bar that displays above on top of every other object in the prototype. Neither of these is severe, but they do require a little work.

Problem 2

There seems to be a bug using overlays that are not full-screen in Framer Flows on Android, sometimes “flow.showPrevious()” events trigger from user interactions with UI objects not bonded to that flow event’s respective event handler. I have found this behavior to be completely unpredictable. The primary event I have been solving for is using an overlay flow event to show and hide a keyboard. Often on Android, tapping out of an active keyboard to close it transitions to the previous screen, instead of the expected behavior. Here is the video of the bug I showed in my previous post.

My Android Solutions

Solution 1

The main course of action in solving the first problem is setting up the Sketch file. From there, it’s only a few lines of code to have everything up and running.

Step 1: Setting up the Sketch File

Using the original Sketch file from the previous post as a starting point, here is a step-by-step process to make it Android ready.

1. Make a copy of the original file, and add “Android’ onto the end of the new file’s filename.
2. Select all the artboards and add “Android” onto their names. I use the Rename It Sketch plugin to do this efficiently.
3. Copy and paste an Android status bar and bottom navigation from another project, UI kit, or create your own. Scale them up to the correct width of your artboards if needed.
4. To make the status bar Android specific delete contents of the iOS Status bar, then copy and paste the new Android status bar layer group into the old iOS status bar artboard. Add 10 px to the height of the artboard to accommodate the taller status bar.
5. Select the bottom navigation layer group, hit “cmd-a” and create an artboard with the selection. Rename the artboard using the naming convention, and the bottom navigation is ready to go.
6. Select every layer except the status bar and the bottom navigation, remove 100 px from their height, then move the affected elements up by 100 px.
7. paste in an Android keyboard, scale it to the correct width, rename it, and your Sketch file is ready to go.

Here is a video I made of getting the Sketch file ready, I went slow, and it still took less than three minutes. The only thing the video is missing is creating the keyboard.

Grab the Android ready Sketch file here

Step 2: Importing the Sketch File into Framer and Copying Over Some Code.

Create a new Framer project and import the Sketch file. Copy and Paste all the code from the previous Framer project except for the “keyboard events,” and add “Android” to all layer names that need it, e.g. flow events, the header, etc.

Make the bottom navigation a Framer Flows footer and assign its parent to “all.” Setting it as a footer with a parent outside of the flow component ensures that it will always render on top of all other layers.

Set the height of the overlay on screen4 “s.screen4OverExampleMobileAndroid” to its height plus that of the bottom navigation. Without this step, the overlay’s “maxY” value will be the Framer Flows default of the bottom of the screen, and its children will all be 100 px lower than they are in the Sketch file.

At this point, problem 1 is solved.

Solution 2

Here comes the hard(er) part, setting up a keyboard that does what I want it to do. My solution is a little “hacky,” but it fulfills my success criteria, and is the most reliable of my keyboard solutions.

Go back to Sketch and create a layer group in the keyboard artboard that is a transparent rectangle the same width of the artboard, and the height of a user journey screen artboard minus the keyboard (1184–458 = 738). Make it a group, rename it “keyboardHider,” and set it outside the bounds of the artboard by putting it above the keyboard, without resizing the artboard.

Keyboard with “keyboardHider” layer

Step 1: Set the Parent and Default State of the Keyboard

Import the Sketch file back into Framer and set the keyboard’s parent to “all,” this ensures the keyboard will always show over everything except the bottom navigation. The keyboard should now show over the first screen and above the bottom navigation.

Set the default “y” value of the keyboard to the “maxY” value of the bottom navigation so that it sits below the screen. Now, the first screen looks as it should, and the keyboard is already loaded.

Step 2: Create an Array and For Loop

With a keyboard that lives across all screens, it’s possible to place all UI elements that cause the keyboard to show in a single array, then use the contents of that array to show and hide the keyboard.

Create an array called “inputArray,” then add all user input objects that trigger the keyboard.

Create a boolean value “keyboardShown” and set it to “false.” Then create a for loop that listens for events on the contents of the “inputArray.” In this case if “keyboardShown == false,” then clicking/tapping on one of the input objects sets the boolean value “keyboardShown” to “true,” and shows the keyboard by changing its “maxY” value to the “y” value (top) of the bottom navigation.

Here comes the “keyboardHider” layer; within the same conditional set “keyboardHider’s” “y” value to “0,” thus when an “input” object is clicked/tapped the “keyboardHider” extends from the top of the keyboard to the top of the screen.

Next, set up an event handler that hides the keyboard when the “keyboardHider” is clicked/tapped when “keyboardShown == true.” This event handler hides the keyboard, moves the “keyboardHider” down below the bottom navigation and sets the “keyboardShown” boolean value back to “false.”

Move the keyboard user events from the original prototype into the for loop, and tab them over until they line up with the “keyboardHider” interactions interactions under the “if keyboardShown == true” conditional. Remove any flow events that came from the previous prototype.

Add the same logic that hides the keyboard when the “keyboardHider” is clicked/tapped to the keyboard user events.

Now, when a user taps into an input field the keyboard will show, if they tap out of it, the keyboard will hide, and nothing will change. If they tap the keyboard’s keys when it’s active, the keyboard will hide, and the input fields will fill.

Here it is in action

Sometimes, if I tap in and out of the keyboard as fast as I can on my old Galaxy S5, the keyboard can get stuck, but tapping the keyboard’s keys hides it and fills in the respective fields. I really have to work at tapping quickly to make this happen.

Grab the Android ready Framer project here

Key Takeaways

The workflows in this post, and the previous, should create a good foundation for you and your team to make complex, end-to-end prototypes. Prototypes that are responsive across multiple mobile devices, only require one or two Sketch files, and can be tested with remote users.

I’m working on a solution for modals on Android and can post it if it’s helpful. Please do reach out if you have any questions, improvements, or help with adapting anything to your specific applications.

The third part in this series will detail adopting this workflow for other screen resolution ratios, like tablets.

Thanks again to Charlie Deets for his workflow, and his snippets that provided the springs for the keyboard animations in this prototype.

Thanks for reading!