General App Development Improvements

Product Suggestions
1

Hey Guys!
Here’s a list of some of our friction points. Let me know if you have any questions or need to provide more detail!

  • Layers. Even something as simple as Foreground, mid ground, background.

  • Ability to group objects together (So they can be moved as 1 unit. Especially useful for shapes, with text on top, with a button on top of that.)

  • Ability to lock objects without setting them to Master. A lot of times we want to lock an object so it never moves, but it’s only on a few slides.

  • Create our own gauges

  • Ability to manage administrative level settings like:
    Loop Protection (Turn on/off per app or change the count)

  • Syncing blink

  • Edit the same parameters across multiple of the same type of object (font size across multiple objects that have font size as an option) When selecting 3 rectangles, I can’t change the size of all 3 rectangles, but instead have to select them individually.

  • Ability to organize tables into folders, and/or other organization features (e.g. Production vs. Sandbox) or Group/Tag/Identify Tables

  • Show which column is doing the sorting in tables.

  • Ability to sort People list

  • Create dashboard analysis based off table data

  • Ability to exclude variable data from completion records.

  • Selecting a Default app/groups to workstation or units (Or apply settings en masse )

  • Workstation UI is really bulky and hard to use/read.

  • Ability to choose on the connector whether you want to use sandbox or production connector (Currently we have to work around the way Tulip assumes it knows what we want to use. It would be a lot easier if I could call Connector A.Sandbox or A.Production to designate which connector to run.

  • A permanent “Undo” button.

  • Set default Aspect Ratio ourselves

2 Likes
2

Brad,

Thanks for the great list of suggestions. A lot of these are related to current efforts, or would be less important once we ship other features:

Layers, Groups, Locking - each of these three features are aimed at reducing app complexity. But perhaps it takes too many widgets to do simple things? One of the things we are working is a ‘no code component builder’ that would let you assemble widgets in a new shared asset type --a component. Components would have advance layout logic and take inputs, so that the same generic components would be useful in different contexts. Layers, groups and locking might still be important, but we want to make sure we address the root cause first. Our team will be sharing some designs and soliciting feedback on the component feature soon.

Gauges - could you talk a bit more about what types of gauges you would like to see? perhaps you have an image in mind?

Loop protection - I’m very curious what is your loop use case? I have seen people doing loops to update records, and we are working on better tools for tables and how they integrate with apps. I agree we might need these safe guards, but I’d really like to know why you need so many loops, because that suggests to me you have run into a more fundamental limitation of the platform.

Visible column sort - usability quick win, we will make it so.

Ability to sort people list - A grid view needs to be a standard option across some of the other asset types in the Tulip systems, and once we do so we can also make sure we universally support obvious affordances like sorting.

Revamping analytics and adding support for tables is something we are actively thinking about. stay tuned.

Excluding variables from completion records - this is shipping soon. We know there are a lot of variables that are only useful in the runtime context, and they just clutter the analytics editor experience.

Selecting a default app/group to workstation - Do you usually assign a single app, a single group, or something more custom to stations? I also think stations with a single app assigned should be a very different experience than with multiple apps to choose from. In that case the app and the station are one and the same, and there might not even need to be an app listing menu.

Workstation UI - you are referring to the menu on the player? One of our newer designers @Aby is just wrapping up some design proposals and is looking for feedback. I’m sure he’d be interested in reaching out to you directly for feedback.

Choosing a connector - Could you help me better understand this work around? Right now we allow users to define a different configuration for whether an app is published or the version. Would you prefer that from the player side you could flip between which version of a connector use for that app running in that moment?

Undo - We did recently add some layout changes to the undo queue in app editor. A first class undo will be coming once we refactor some of the editor code.

Aspect ratio - Do you want to be able to set custom aspect ratios in the definition of the app, or are you requesting that apps better resize to fit the device they are running on? In either case, I agree that there are many use cases for more customization of size and we can explore making that possible.

We’ll be checking here and corresponding much more often. Looking forwarding to discussing more.

Mark

1 Like
3

Mark,

Thanks for the in depth response!

Layers, Groups, Locking - It sounds like Components could be helpful here, but I don’t know if they will solve all the problems these 3 features are aimed towards. Layers, Groups, and Locking is mostly aimed at the ability to create seamless and consistent designs. If we design an app with a “Home” button on every slide, if that button moves even 1 pixel it’s noticeable when moving through the slides. So the ability to lock that 1 button so it can’t be moved or altered until it’s unlocked. In the same respect, the ability to group things makes it easier for us to maintain consistent spacing in relation to each other. when moving from 1 app to another. Ultimately layers helps us from a development side create faster by making fewer errors. even if we only had 3 layers (Background/Content Layer, Midground/UI Layer, Foreground/Interactive Layer) we’d run into much fewer issues trying to edit and improve our apps.

Gauges - When I think of gauges I think of visual metrics, so more of an alternative/extension of analytics. Thinks like dynamic current -> Goal charts, progress bars, pie charts, etc. Quick and easy comparison of variables to convey information to my end users.

Loop Protection - We use Tulip as a front-end for our ERP, Netsuite. We push and pull a decent amount of information on a regular interval. For example, we pull from NetSuite every 60 secs every new repair. Then we parse that data and store it into tables. Currently there’s a limit of ~15 or so triggers before the protection kicks in and stops. We’ve discussed making each trigger bulkier and have them do more work, but it feels very clunky.

Selecting a Default App/Group to Workstation - Generally we assign a group. But if for instance if we open a new location with 30 locations, I’d have to create the Station Group, create the station, assign each computer to their unique station, then assign the app group to those stations individually.

Workstation UI - The station page on the back-end where we manage stations and assign computers/apps in general is not user friendly. The numbers for each station group total up the number of objects under the group, not the total stations. There’s no sort, filter, or search functionality. We frequently find end users who we somehow managed to miss assigning them the default app group. When we roll out new apps, it would be nice to be able to filter by that app to see all the users currently in-app.

Choosing a Connector - This problem stems from the interaction between apps being published/unpublished and sandbox/production in connectors.

  • If you use the dual connector (Prod and Sandbox in one) and you are working in an unpublished app, the connector uses the sandbox link because it assumes you don’t want to use production because the app is not published. (Which is a logical assumption.) the problem is, that means the only way to verify your production is working as intended is to publish your app. And if you are working on an app your end users use every day, it’s going to impact them.
  • So what we did is create 2 single connectors (1 for Prod, 1 for Sandbox) and test using our Sandbox connector and before going live move to our production and test again. At that point though, we are maintaining 2 connectors to ensure they are exact copies of each other. Which generally means deleting SB, copying Production and editing it to work with SB again.

It would be awesome to use the dual connector, but instead of platform deciding which connector to use based on if an app is published or not, if we could just call an extension of the connector. So Connector.Production or Connector.Sandbox to decide in-app which i want to use.

Permanent Undo Button This was in regards to the fact that the undo button disappears after about 10 secs.While an undo queue/history would be awesome, even making it to where the button doesn’t disappear and we can always undo the last change made would be helpful.

Aspect Ratio - We buy 1 monitor for most of our end users to use. It’s a 16:9 Aspect Ratio. that means, EVERY app we create we have to remember to change it from the default of 16:10 to 16:9. if we could set default values like this in a mater settings page, it could go pretty far with quality of life. Because we build a UI for most of our apps, we actual prefer the aspect ration not be mutable by machine.