Hey I created a table that has all our company colors logos etc and was wondering if I can push that information into the base layout.
For instance, I would like to be able to update the table and have it dynamically update all apps if I wanted to change a color in the interface. I know that you can create the variables for the base layout but is there anyway to tie those variables in the base layout to tulip table data?
@Shrmnatr, this is a great question. I’m curious if there’s a better way to do this, but off the top of my head: you can’t link table record colors to assets like buttons of shapes, but you could write a trigger that pulls colors from a table and stores those colors to variables. If your IDs in the table map to the base layout variables, you could have fields for the different color scenarios you’re envisioning.
Looking up answers to your question led me to [this post] from 2020 (Table Color Driven Shape Colors)t by my colleague @Pete_Hartnett when he was Tulip customer.
What do you say @kimberly? Any thoughts from design on this?
This is an awesome idea, and a really clever way to work with tables! @John’s solution seems likely to work pretty well for this. @Shrmnatr, if you’re up for it, it’d be great to see how your apps are structured and how you came to the table idea - my team’s been thinking about how to make using company colors in apps more easy and would love a customer perspective.
Compagny and/or workspace level will be better when workspace is managed by different brands with different visual identities
@kimberly: So I don’t know how much structure we have yet haha. I have headed up tulip development for my site and have been creating a wiki to document how to do variable names, typical work instruction flow etc. and as I have been developing work instructions I am a little torn now as to whether you build a table first, or the work instruction first or a combination of both. I really only have one well developed application so far, but I am happy to show you what we have done.
@John thanks for sharing! I actually came across the same post and was testing out trying to create a trigger to pull that info in. I just worry if introducing a time based trigger like this would cause some issues with the application in the long run, can it be a on startup trigger, or is there an example of how you would do this?
@Shrmnatr The optimal trigger depends on your app structure and your use case.
You could do it on the on step enter on base layout. If it is a lot, you could catch it with a “already checked for color” boolean variable.
(If colorChecked = false then … get the colors and set colorChecked = true)
@kimberly I find this is a uncomfy workaround.
I would love to have a Table in the Settings page where you can set several presets for each widget and base layout. In app you can choose one of the presets.
That would be a simple solution and has a lot of advantages:
And all of that without any trigger construction to load colors from a table
What do you think?
@John / @kimberly /@youri.regnaud / @thorsten.langner
So I was able to get my idea working and have a base layout pull the table information at the beginning of the application. The main purpose behind my idea is to ensure continuity across all the applications developed at the company. Honestly what would be really awesome is if you could create a master layout that affects multiple work instructions. I know you can copy a base layout multiple times, but if you make a change to one you have to update them all. What feature would be great is if you can create a master layout that affects all work instructions.
Here is what I was able to build:
Which this does work, however it makes it really challenging to build the rest of the interface in the application because there is just the marker for each symbol and since nothing is assigned a color until it loads some things are invisable.
Yup that is essentially what I would like to have. However I would rather have it not in a table based environment at least on the front end, as I mentioned in my latest post It is pretty difficult to work around the table idea because it is a visual interface that will need to be worked with as well. It would be nice to have a higher level base layout that you could nest applications under that acts as the main layout for all nested applications.
This may be too much of a work-around to be of interest, but I thought I would offer this suggestion anyway. I think the product will need to come in to make these sorts of things more easily achievable… i love the idea of a shared base layout that can be updated and referenced in other apps. I also like this for other steps like defect logging steps, for example. The more composable, the better!
At any rate, there is a wacky way to achieve this if you want to play with the idea. Custom widgets can be present in many apps at once and base layouts sit behind all other steps.
So here’s the idea, you could have a custom widget that just prints out your theme in the background, devoid of buttons and things, but it could also carry along with it a bunch of variables that could be used for button colors.
Here’s the wild part, since custom widgets are locked once they are in a published app, you could actually make the widget somewhat of a conduit for a table record. The app open would load the “theme” you want, and it would inject html into the widget as well as some colors. Then the widget would be styled behind your app and all of the colors would be exposed as usable variables.
Sounds fun!
By the way, I did try this and it seems like it works. You still have the Load table record on app load issue but you avoid the need to have all sorts of color variable loads.
Also, if you wanted to get real creative you could embed other logic in the widget like default click behaviors for menu buttons, next/previous, and other “settings”. You could also switch table records on certain steps to change the template.
I don’t hate the idea, to be honest, and I think the product team could use something like this as inspiration for a new feature. Let me know if you want to collaborate, I’d be happy to build something like this out and add it to the library as a quick tip (and possibly a widget… though I like to keep hacks to a minimum in the Library. Sometimes I can’t help myself)
What do you think about this idea?
Happy to collaborate. I honestly think a master layout that affects tied in base layouts would be the best solution so you don’t have to develop an application with no pictures or color and you get the benefit of automatically updating many applications at once. Just let me know when you guys would like to collaborate I would be happy to.
