Basics of Mobile Card Builder

No, Mobile Card Builder is not another solitary-like game available for your mobile device.

Unless you enjoy building UI views for the data elements and UX rules based on these data. I don’t, but sometimes you have to do it. Thankfully, after you read this post you will have enough knowledge that you can introduce it to your designer.

What is a Mobile Card Builder?

It’s a plugin that allows you to create basic cards and templates that will be later available in your mobile experience config. You can install it for free from the plugins page (app id: sn_mobile_card_bui). It has a pretty nice documentation page. However, it doesn’t cover everything, especially the more complex topics for field value assignment and mobile ui rules. I will try to fill the gap and explain shortly some basics.

Open it up!

Once installed, the application will be available under the System Mobile module. When you open it, you will see a welcome screen with some interesting design choices made already here: Where is the <Open> button?

Take another look, it’s there, hiding in plain sight in the bottom-right corner.

On the top, just below the dark banner (not immediately visible in my opinion) you may notice tabs – cards, card templates and legacy cards. If you want to go straight to the designing, you will quickly get confused in the interface. So first, let’s define the basic terms:

Now, let’s take a look at the first point of interest and – surprisingly – second tab, the templates.

Card templates

Pick any template and load it. I chose Genius Result Service Catalog:

You may notice some interesting facts:

Some elements can be removed, but not all. Why? Those which you cannot remove are connected with data within one of the cards using this template. I’m telling you this because the tooltip is not helpful:

When you want to save, you don’t have to worry about the scope – if it’s incorrect, it will be changed without any notice, question or warning message. Talk about citizen developer friendly interface, right?
You have no hint about table name holding that template. But it is stored somewhere on the platform. Another citizen developer friendly feature, minimize the technical details.

So where does it sit? The table name is sys_sg_view_template. By default, it shows the JSON data for the template and references to every connected element (label, button, container, icon, image, …) -> table for those is sys_sg_view_template_slot.

Cards

Now when we know something about templates, let’s connect them with the actual data from the platform. I’ll use the Catalog Genius Result View card since it uses the template discussed before. The interface is very similar with small differences from the previous one:

As you can see, instead of text placeholders we have the actual fields from the table. Which table? The one from the top-left config (hard to see, I know). Some interesting facts here:

You can change the table (click on Menu and pick Change table). This time, you will get a warning:

You can’t change the properties of the template elements (text color, height, placement, …)
You can’t add new elements
And you can’t recreate the columns.name mapping for the biggest placeholder in the middle… Wait, what? For some reason, in this example the columns do not provide dot walking from the Mobile Card Builder interface (but the type do allow it). But there is a walk around! Of course, somehow this field got mapped

The card sits in the table sys_sg_view_config. When you open it, you will notice that mapping a field to a template element is not that obvious.

You have card elements (sys_sg_view_config_element) connected with the card template elements (sys_sg_view_template_slot)
Card elements are also connected with the card element attributes (sys_sg_view_config_element_attribute). Out of the box we have 25 attributes:

So even though the Mobile Card Builder has been created for the citizen developers, not everything can be done by them.

Mobile UI rules

There are also mobile UI rules. You define them on cards. You can use the mobile card builder for the simple ones. Depending on the data field type mapped to the field (nothing to do with the template!) you may see different options available.

These rules sit in the sys_sg_ui_rule table. When I’m writing this article, working with mobile UI rules has already been greatly improved. I had a hard experience with them in Utah release. Glad to see this is better now!

Conclusion

Feel free to designate a designer in your team to create some templates for you. Then you just map the data, maybe create some UI rules and you are ready to display it in the Mobile Experience! It’s not that hard, is it? Make sure to also read my Basics of Mobile Experience post!