Tulip is working on some exciting new things for mobile! Ahead of these new features and tools, we’re releasing a new Tulip UI Template for Mobile Apps.
As a designer at Tulip, I also wanted to share some best practices for designing mobile apps:
Keep it Simple
Mobile screens are small. Keeping content to a minimum allows users to focus on what’s important. This applies to widgets, text, and navigation. If a step is feeling cluttered, consider breaking it up into multiple steps and editing out content.
Small Screen ≄ Small Components
On phones and tablets, users generally interact with apps using their fingers. Keeping tappable components above 44px x 44px will make them more user-friendly. Text is harder to read when small, especially when someone is holding their phone far from their face. The smallest font size you should use is 13pt, but consider going larger.
Test Before Publishing
Always test your app in as close to the environment the app will be used in as possible prior to publishing. Visual elements and interactions will look and feel different on a mobile device than on the computer you’ve built the app with. Is this app going to be used at a single station? Are users going to walk around with their devices? What is the lighting like? This will help you verify everything is readable and usable.
If you’re interested in learning more about mobile UX, one of my go-to resources is the Nielsen Norman Group. Just about any question about user experience can be answered in their articles or videos. You can find a list of articles about designing for mobile and tablet on their website.
What other resources for mobile UX/UI best practices you’ve found helpful?
Very interesting, thank you. I am looking for training, best practices, … to learn how reduce cognitive load of frontline workers and try to reach a new step for our Tulip apps. Some ideas?
The first tip around keeping it simple definitely applies to reducing cognitive load. Reducing visual clutter is really helpful for focus. Using a template (either from the Tulip Library or making your own) or some other form of a design system can help. When the UI is consistent from step to step and app to app operators will have to spend less brain power processing the UI.
Hi @richardg, I’ll see what @Katie_Stakland thinks, but my recommendation would be to have two separate applications—one optimized for tablet and one optimized for computer.
In terms of logic and functionality, the apps could be exactly the same. The benefit is see here is mostly in terms of ease of maintenance. Rather than needing to have a single application with step groups and transitional logic based on display device, you can create apps for different display device types and assign them to devices/stations as such.
I agree with @John on having an app designed for tablets and an app designed for computers. They can be mostly the same (which will make building them easier), but that way you can tailor the UI to the proper screen resolution.
Using separate apps I would still have to rely on per station app assignments or create mobile station groups.
I could also see perhaps making separate steps in the same app with logic to jump to the mobile pages under some sort of condition. This would be beneficial with GxP apps as the validation would only have to be performed once.
I don’t think there’s any way with the current trigger logic to know if you’re on a mobile device though…
So things I see that would make this easier / more scalable:
A way to detect if we’re on a mobile device or not, AppInfo.<something>
Global application functions that can be used on any step, so we don’t have to duplicate trigger logic.
@Richard-SNN I have one app where I move the user to a different Step Group based on device type.
I have a Stations table with every station name listed in the ID field and a manually populated Device Type field for Computer, Tablet or Mobile.
In my app I have an On App Started trigger to load the current Station into the Stations table placeholder, and then based on the Device type transition to the correct Step Group.
In addition, within the app I’m able to make generic triggers that take the device type into consideration before transitioning to steps as shown in the expression editor here:
I see the Tulip team is recommending different apps so maybe this isn’t best practice but has been working for me. It’s nice to launch a single App and have the app figure out what step the user should move to based on device type.
Hi @doneil, thanks for sharing this! This is the first time I personally have seen this kind of routing based on an end-users display device. Just because I haven’t seen it before doesn’t mean it isn’t a valid (and very clever!) way of solving this problem. I’m going to share this thread a little more broadly with the team. I think this is a really great topic for discussing design best practices and app management at scale.
Let me ask you some follow-ups, @doneil. How’s this method working for you? Does it solve the problem effectively? Any unintended behavior? What alternatives did you try. I’m very curious to hear what you tried and how you arrived at this solution!
Just wanted to follow up here. Consensus from the team is that this is a great solution to this problem, and that there are other Tulip users out there who do something similar.
Thanks again for sharing @doneil, I think this is something a lot of folks will find useful!
Hi @John this has been working great for us as this app is acting like a launcher app that based on what barcode we scan pushes the user into different apps. When the users complete those apps, it pushes them back to the Barcode Scanner app. Most of the apps can be completed on both a computer and a tablet so it’s nice to just forward the user back to a single Barcode Scanner app without needing any trigger logic to decide which barcode scanner app they should be forwarded back to based on the device type.
The only issue I run into now (that is completely avoidable) is when I add a new station, I sometimes forget to add it to the Stations table as well and define the device type. I could also add a “Configure” step in the Barcode Scanner app that if the Station doesn’t yet exist in the table allow the user to define the device type, but I probably won’t go down this road.
I actually didn’t try any alternatives. I already had a Stations table which I use to pass a part serial number from Barcode Scanner to the next App that is loaded so when I decided to add a Mobile format to Barcode Scanner I came up with the idea of adding a Device Type the Stations table. It was a few versions later I realized I could simplify the triggers to use an expression instead of a bunch of If–>Then, If Else–>Then, etc.
Looking back on everything I’ve learned since; I think I would still build this the same way for simple apps…all formats in a single app. If the app was far more complicated or if the function/purpose of the app varies between device types then I would want different apps for each.
Going forward I think it would be great if Display Type could be added to the Display Devices screen where we could define what Type each Display is…should be up to us to decide: Tablet, Computer, Windows, Mac, Touch Screen, Phone, Stationary, Movable, etc. Then as @Richard-SNN mentioned use that parameter in the app without needing to maintain a separate table.
