In Praise of Globals, but…

Elements Feedback
1

Elements is shaping up to be a fantastic product with unlimited potential. Even in this beta stage, I’m thoroughly enjoying working with it. It’s a breath of fresh air compared to Classic.

But one of the eye-opening features is globals. It is amazing what one can accomplish with globals; they can be real time-savers.

The ability to change styling across many elements is genuinely impressive and productive.

As I work on porting more websites over to Elements, I use globals to provide consistency across the different sites.

But…

With tremendous flexibility comes some danger.

It is possible to make unintended changes accidentally. For example, if you accidentally click on and move a component within a global, it will reset the content across all instances. Then, there is the constant problem of forgetting to OVERRIDE a setting when you make a change, only to see the change propagate across all instances.

So, I want to see some guardrails built into Elements to deal with issues like these. When moving a component within a global, Elements could warn that you are about to impact all the global instances. Likewise, if you go to change a setting, it will warn you that it has not been overridden, so do you want to proceed? This cuts both ways, as you might want to change a global value instead of just in the local instance. So, it would not be enjoyable if it kept asking permission. But I’m sure a solution could be found.

To ensure consistency across my sites, I created a project to set up several globals that I then use across my sites. These globals cover many HTML elements utilized throughout a website, such as headers (h1, h2, h3, h4, h5, h6), paragraphs, etc. They are all preset with generic properties that will make those elements consistent. I then drag them from this project to the one I’m working on and when I get them there I convert them to a global in that project.

CleanShot 2024-12-29 at 19.12.47@2x
CleanShot 2024-12-29 at 19.12.47@2x782×1508 22 KB

This approach is not as convenient as it could be because globals are not global. They are only global to a project. I want and need globals for all my projects. So, if I make a change to one, it will propagate across all of the sites utilizing the global. To achieve something like this, there would need to be a distinction between an actual global and a local one. But it seems doable.

Due to the number of globals I utilize, I would also like to see them reside in a separate sidebar instead of mixed in with the core and custom components.

This feature is so powerful that it requires some guardrails for the novice user. Speaking from experience, I just had it happen twice in one day. I had set up 40 cards from a global when I accidentally moved a component while trying to edit some text inside one of the globals. All the text in the 40 cards was reset, and I then had to go back and override and reenter all that text. It was painful. This was mainly because UNDO had no support which could have restored the change.

Even if the user experience were not improved, I would not give up globals for anything; they are unbelievably convenient.

1 Like
2

@dan I wanted to add some more feedback on the idea of guardrails for globals by citing an experience I had today with globals.

I have a need for a global detail card on one of my sites that is used in a LOT of places. I had setup about 50 of these cards and dutifully overrode all the bits and pieces that I needed to customize each card. I needed to edit one of the typography components in one of these cards. So I double-clicked on the card and inadvertently moved my mouse a few pixels. Elements thought I was MOVING the component and moved it out of it’s container. I obviously freaked out and did an UNDO. No go! This particular portion of the global was reset to the default text and I lost ALL of the detail I had entered throughtout the day from all of the cards. OUCH.

If Elements had asked before performing the move I could have avoided a lot of pain.

This has forced me to face reality, which is that I cannot safely be building out this type of element until there are at least some minimal guardrails in place. For now I will just add the globals where they are needed, without the specific content.

This is not the first time this has happened, but I’m hoping it is going to be the last one.

3

YES! I agree, Globals with the overrides are a killer feature, I really wouldn’t want to work without them — They just need a little more finessing to make them 100% :ok_hand:

And yes… Undo was working, but it’s very broken in the current beta :grimacing: We plan to fix this up very soon, and once that’s done you’ll be able to undo any accidentally changes :sweat_smile: should make working in Elements a lot more relaxing!

I also agree that we need to put a few minor guardrails in place, but that should be fairly trivial once undo is back working!

Lots to do, but we got this. Thanks for all your feedback as always :saluting_face:

1 Like
4

I’ve set up a global footer and I need to change the text size for the various breakpoints but I can’t seem to get the Global Override to work on each breakpoint.

I go to the Breakpoint and click Global Override

I Unlink the text size and change it

But it still changes on all the other Breakpoints

Am I doing this wrong?

Assistance would be appreciated.

5

Hi @handshaper,

I had a similiar question a few days ago and @dan pointed me to Templates. Those are still in progress. But I would see a potential there to setup the layouts and control the design over the Theme Studio.

Cheers
Nicolas

6

Did you start on Base Level and work your way up?

7

Hmmm, I think you might be getting the responsive dots and global override links confused — Can you share your project (or screenshots) showing what you’re trying to do?

8

Yes, a template would work for the initial creation of something like a footer. But you would still need to turn it into a GLOBAL to use on multiple pages. A template will not give you the same behavior as a global. Although having not seen templates yet that is pure speculation. Maybe you can apply a template on each page and then edit the template and have it update all of the instances. Although my feeling is that would defeat the purpose of a template, which should be intended for general use across multiple projects.

We’ll have to see what templates look like when they arrive.

But my original comments were regarding globals in general and how easy it can be to shoot yourself in the foot with them.

9

Oh well,

maybe I missunderstood. They way I read the post I thought you are using your global as there are no templates yet. But yeah lets see how they look in the future.

10

No, I’m using a GLOBAL because I want to be able to change the styling if needed and have it propogate through all of the instances. It is unclear how Templates will work, but personally I would still use a global, even if it started from a template.

1 Like
11

Is there a reason there’s no tooltips? I’m guilty of clicking the wrong thing way too often.

12

Using Globals should be A LOT Better now, we have multiple undo for starters, and have done a lot of work around making the Globals more rubust in general (although we do have more to do!).

They are getting bettet and better all the time :blush:

1 Like
13

I have noticed things are improving. Although I have run into a couple of instances where UNDO did not fully recover what I lost when an inadvertent move happened. I’m now confident enough with them to start populating them with the real data. Was waiting for some improvements.

1 Like
14

Keep us posted, if you find a new issue let us know how to reproduce it and we’ll get it fixed!

15

Just a thought. I think for special gaps and things I would go over the Theme Studio and create custom margins there to then modify them globally.

16

Yes, that is a perfect way to do it!

17

@dan I just ran into an issue again with GLOBALS. I have a global that is used to display a definition as shown below.

CleanShot 2025-02-22 at 15.41.25@2x
CleanShot 2025-02-22 at 15.41.25@2x942×302 40.2 KB

I was editing the text in RED when I accidently moved the text component (need to be able to lock components). Of course this cleared all of the text in all of the definitions on the page. Performed an UNDO and most of the custom text came back. EXCEPT, the text shown in RED above was not restored with the undo.

Not sure why it was not restored with the UNDO. Possibly something to do with the fact that this block of text had been formatted inline to change the color and italicize it. It was not a separate Text Component.

Fortunately, I had not done a SAVE so I quit and restarted and I got everything back, phew.

Anyway there appears to still be a case where an UNDO is not fully restoring the text. I’ll attempt to create a test case in a smaller project in case you need to see this in action.

UPDATE: I have done a lot more testing of this problem today. I discovered that an accidental move will reset all of the text in the text block back to the default text. UNDO will only restore to the default text and move the component back to the original location. So it was losing any text that was entered. It is amazing how easy it is to accidently move a component. I’m now completely convinced that some sort of locking mechanism is going to be crucial for safely working with globals. The upshot is that while an UNDO will save you a small amount of work, it does not solve the problem at all. A move of a component in a global should be prefaced with some form of alert asking if you REALLY want to move all of the instances of the component. It would also be handy if a move did not automatically trigger clearing the contents of the component.

It amazes me how easy it is to accidently move a component and just how much work you can lose. Today I had this happen twice and was forced to re-enter text in 64 globals, ouch. I’m going to be forced to hold off adding custom content to the globals I’m using until there is a safer way to work.

1 Like