BACKLOG: Site Information Enhancements/Fixes

Treepl Backlog
1

A few minor adjustment requests for Site Information module:

  1. dateTime field is still just a Date field. Is it possible to update this to select Time as well (as per dateTime field update throughout the rest of the admin)

  2. When setting an Alias (particularly a ‘Short Alias’) there is a validation that runs to check for conflicting names. However, this seems to look at ALL properties in ALL groups, not just the group you are in, which starts to make it harder to set up short aliases.
    For example: In a group called ‘Company Info’ with a property of ‘Licence’ you might have Short Alias of {{si.ci.l}}
    Then in another group called ‘Company Branding’ with a property of ‘Logo’ you might want Short Alias of {{si.cb.l}}. But the validation only checks against the last Liquid reference of l (which conflicts) rather than the whole path (which is unique).

  3. The textarea field type is labelled as Text (Multiple), but I think it should be Text (Multiline).

  4. While I’m here, may as well request all other field types be added :slight_smile:
    ie: Checkbox, Dropdown, Listbox, Radio, and Boolean.

1 Like
2

Great @Adam.Wilson - Needed the dropdown the other day as well :slight_smile:

Added here: https://treepl.co/public-backlog-state/request/site-information-enhancements-fixes :+1:

3

I have some further improvement suggestions for Site Information.

@Peter-Schmidt not sure if this is best added to this current Backlog Item or if it should be it’s own new item??? Perhaps add to this one and let the team decide?

So here goes:

Firstly, the Site Information functionality is probably under-appreciated and I think with a handful of improvements it could really be a very powerful feature.

The following suggestion adds a kind of ‘Layout’ option to Site Information as well as a small UI tweak.

Ideally, Site information should be raw data/values that admins can easily edit, without having to worry about how or where that info is going to be used and certainly not having to add/edit any extra markup around that info (which might not be relevant in all situations).
But often this data needs to be further wrapped in markup depending on how it’s being used and if the client is the one adding the Liquid aliases to a page they may not always implement it correctly.
Email addresses and phone numbers are basic examples of this, where the client might simply add the Liquid snippet for a phone number onto their page, but ideally, we’d probably want to see that number formatted with the correct anchor markup (eg: <a href="tel:+61243999888">02 43 999 888</a>).

This is where a ‘Layout’ for Site Info values could come in so that the developer can set up a fully marked-up version of the Site Info tag.
This is a bit like what happens with some of the eCommerce data where we can output a raw price value (ie: {{this.price}}) but also output a correctly marked up HTML version where needed (ie: {{this.priceHtml}} which is wrapped in system-specific HTML markup)

Here’s a possible UI for this when first creating the property:

si-html-layout
si-html-layout1592×908 124 KB

Then, in the Toolbox we’d have the ‘HTML’ alias option to copy/paste as well as the normal alias.

Obviously, it would be extremely powerful if Liquid was available in this layout field, at least so Liquid filters could be used to further manipulate the data, but also to interact with other Site Info or CMS data.

The example for a phone number layout might be as follows (where the number is just entered in a local format 02 43 999 888):

<a href="tel:{{this.value | remove_first: '0' | remove: ' ' | prepend: '+61' }}">{{this.value}}</a>

Rendering:

<a href="tel:+61243999888">02 43 999 888</a>

Not sure is {{this...}} would be the right Liquid reference here… perhaps just using the actual alias would be better???

Additionally, I’m not sure if multiple ‘Layouts’ would be overkill here or if just one is enough… but something to think about…?

The next part of this is just a UI adjustment.

Even with Site Info as it currently is, so many times I’ve clicked to edit a property and started changing its name rather than the value because the ‘name’ field is at the top and the ‘value’ (the bit you’d only ever want to change) is at the very bottom. Clients could easily mess this up before they realise I think.
So I’d like to see the ‘value’ field and save button moved to the top when editing a property and having all the other details disabled with a separate ‘Edit’ button if you want to activate those fields for editing:

si-editing
si-editing1591×973 125 KB

Open to other thoughts/ideas…

2 Likes
4

I support both of these changes :+1: :+1: :+1: :+1: