Skip to content
Ideas for Redesign

icon picker
Restructuring Notes

Blocks

Blocks should have a generalised naming scheme - At the moment, every block has a name which doesn’t easily tell someone what kind of block that is, what it does, and if it’s timed or persistent. A new naming scheme could look like:
{BLOCK-TYPE} - {BLOCK-NAME} - TIMED/PERSISTENT
Timed blocks will automatically become inactive when they hit their due date, which can signal their deletion.

Forms - Put them in blocks too!

Forms have traditionally been put inside pages, but this can get messy and difficult to track because each form instance becomes individualised. It would be better to have forms placed in blocks, and then have any hidden fields that require page specific data to be manipulated via Javascript variables set on the page through the inner text of HTML elements. Maybe these could be pulled from an invisible div at the bottom of the page? An example is below:
<!-- This part would be on the page, below the page content -->

<div class="form-details-set">
<p id="campaign-field-set">Campaign Name</p>
<p id="country-field-set">Country Name</p>
</div>

<style> /* Would be in the global CSS rather than on page */

.form-details-set {
display: none;
}

.form-details-set p {
color: white; /* To hide any text just in case something breaks! */
}

</style>

<script> /* Would be in the global JS rather than on page */

const campaignField = document.querySelector("#campaign-field");
const countryField = document.querySelector("#country-field");
let campaignFieldInfo = document.querySelector("#campaign-field-set").innerText;
let countryFieldInfo = document.querySelector("#country-field-set").innerText;

campaignField.innerText = campaignFieldInfo;
countryField.innerText = countryFieldInfo;

</script>

Components

Pages are generally built from individual components, which are manipulated and combined in a way to create one cohesive piece of content. With the Bluepark blocks functionality, we’re not able to bring in and manipulate a component for each individual page, so every component we create will have to be static and reusable across the site. These include things like

Corporate Pages

I’ve long been searching for a way to templatise Landing Pages so that they can be manipulated by non-technical staff members without my help. I think the best way to do this is to have each page be a Product instead of a Page in Bluepark.
This works better in two ways:
A “Corporate Landing Pages” category can be created, which helps group all of those pages together better.
Each page becomes a product, which allows us the full breadth of templating functionality within the Bluepark Template manager. This also allows us access to the 10 Custom Fields available within a product, to additionally customise the page.
The core of the page design can be put in Custom HTML > Product Detail Page within the Template, and then an order for where which content should go can be decided. After that, each person will only have to do basic editing when creating a page, without having to touch any of the underlying code. This idea could also be re-used for other landing pages.
@Andrew Howden
has volunteered his magnificent services to create a backend in Filemaker that will help us accomplish this goal.

Country Specific Pages

I propose a kind of ‘article’ layout for all of the country specific pages, since they’re somewhere between being informational and salesy. We can still have clear calls-to-action and we’ll attempt to make them more visually interesting than a normal article style page would be.
These pages can also follow the same guidelines as the Corporate Pages - creating a template and assigning that to a category page which becomes the main attestation landing page. Each country page can then either be Subcategories or Products.






Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.