Dev Diary Ep18 - The power of using Globals

Hey All,

This weeks video is a big one, as we take a deep dive into the new Globals feature, and show why this is more advanced than anything else on the Mac. We think this is really going to change the way you build websites.

We start with the basics, and quickly more on to the more advanced features you’ll find in Globals. We’re very excited by the advancements we’re making and hope you love this new feature as much as we do :smiling_face:

As always your feedback is invaluable to us, so let us know what you think of today’s announcement in the comments below.

I’ll be back next Tuesday as usual.

Cheers,
Dan & Team Realmac

7 Likes

Okay, we get it. Elements good, Classic now kludgey. And yes, we’ll love Elements.

A few things, though:

  1. The product is Elements. You have defined Local Elements (single elements) and Global Elements (combined elements). You need to brand that correctly in the UI. Maybe the subname isn’t quite right (e.g. Local), but both are Elements, just one is a single thing, one is a combined thing. It isn’t clear from where you’ve been back and forth with the UI that you get that ;~).
  2. I don’t fully like the check the box to override idea, but I have a solution: if you hold down a modifier key (control, shift, option, command) while making a change, the box gets automatically checked (it’s an override I want to do) whereas if I just make the change without the modifier, it’s not an override, it applies to all. You can still check the box (and the box gets checked on an override), but I find the modifier idea to be faster and more direct.
  3. It’s clear that building a site is now going to be a different process. Because of globals I need to define elements that apply across the site (Global Elements) and build them first, then apply elements for a single page that aren’t contained in a Global to individual pages. This needs to be clear in your tutorial/manual from the get go. Menus, banners, footers, are all likely to be best defined as Global Elements. I like this, but is a different up front design think.
  4. It’s clear that global elements need a sub-name. You had two Sections in your latest video, and you didn’t immediately know which was which. When you create a global, we should be forced to give it a user name. Thus, instead of SECTION in the UI, we’d see SECTION — USER NAME in the UI.
1 Like

Okay, I’m starting to get the idea of Globals (still not sure about the name, and the functionality is different than normal elements) a little better now, but the UI/UX around them is a bit confusing. It would be nice to have some visual indication both within the page preview and element list of which elements are global, and which are not.

I’m also finding the global overrides (square) UX in the properties panel conflicting with breakpoint (circle) overrides. Both turn blue to indicate a change, but there’s no indication whether the current value applies to the breakpoint override or the global override. What happens if I override a global override at a specific breakpoint?

Also, at that resolution (~12px), the circle and the square can look quite similar for folks with poor eyesight. I’d suggest a different, visually distinct icon for the global override as what you’re doing is breaking the link for that instance’s property from that of the defined global itself.

Oh, and please don’t hide functionality behind keyboard shortcuts. It can be a convenient shortcut, but it shouldn’t be the only way to access (or discover) a feature.

2 Likes

Hmm, yes, that is something worth thinking about :thinking:

Oh yes I like this!

Yes, agreed!

Yes, as I mentioned in the video that part of the UI is unfinished, we have some plans to make that clearer, starting withering the custom name :smiling_face:

Thanks for the feedback!

Pretty good. Thanks for comparing to partials.

I have a question on how you know which is the “real” global. I guess by unchecking everything you can see it, but it might be nice to have navigation back to the original. Otherwise, checking and unchecking could create a mess if things fairly quickly. Or perhaps a separate button to modify original.

You assume people are at start of website, but some protections for after it is built and more complicated might be wise.

In a database program I use (Panorama by ProVue) they use variables all the time. There are five types: fileglobal, global, local, window, and permanent.

You could also use site element, page element, or stack element probably as well. (Or are you staying away from stacks nomenclature?)

It would be really powerful if you could create an element like Feeds by Joe Workman that can directly feed off databases, in particular Panorama. It would be a very powerful combination (when you run out of stuff to do :wink:

1 Like

I’m wondering if there’s a need for global ‘element collections’ where common elements (global or otherwise) can be managed together, and where all instances of these collections are updated automatically. Similar to page templates/layouts if you will.

For instance, in one ‘collection’ (layout) I might with to include a ‘global’ header, a ‘local’ main section, a ‘global’ footer. I could then add this collection into any page (or create new pages with it already included) and it would remain linked. Then, after a year or so, I decide to replace my ‘global’ header with a completely new design, I only have to change it in one place to have it cascade throughout my entire site. As it stands now, I would either have to modify my current header (thereby removing any possibility of undoing the change), or go and manually update the header on each and every page across the entire site.

Currently it feels as though ‘elements’ (global or otherwise) are being overloaded for the sake of perceived simplicity, which may end up causing a great deal of confusion down the road.

Update: In working with Figma this afternoon I was reminded that they have a similar construct in ‘components’ which are collections of elements that can be used globally (updated-automatically), but also overridden in similar ways to Elements Globals. These are presented as ‘Local Components’ within project Assets, which are separate from the basic elements (text, boxes, etc).

Question: Can you put globals in globals? ie. nested globals?

Ok, the posts from last week & this week I’ve seen are hitting around the problem w/ UI, as this week’s update didn’t really show anything new. Since all elements are being ‘tracked’ using some sort of data, then why can’t Elements add a key/value pair when a element is converted to a global? That way, there’s no need for a second global override. Put all globals in the elements pane & give them a different color & icon to be able to distinguish them as a global for users. When someone uses an override icon, then Elements just knows if it’s applied to a global or not - simple UI. And yes, I agree the override icons are just too small.

If I can suggest something, please make a ctrl+click menu choice!

I like your suggestion of using a link icon for the globals :+1:

Breakpoints and Global overrides are independent. Globals are global and can’t be changed altered at different breakpoints.

If you wanted a different grad at a different breakpoint you’d use the breakpoint feature, not globals. This sounds a little confusing as I’m writing this down, but when using it in practice it’s very intuitive and makes sense - I can show this in a video if you’d like…

1 Like

I get this, essentially, at a break point you are already making changes. So whatever change you make should not affect the global at another breakpoint.

But this brings up another question. Does a breakpoint change to a global, permanently alter the global when reused at the breakpoint size the change was made when used a subsequent time?

Or is a global restricted to use within a certain breakpoint? In practice we need to make 1 global per breakpoint?

This could indeed get complicated if there isn’t a very defined way to assign the modification methods and retain a clear inventory of the project’s elements.

Even on a small site copy & pasting gets boring. :wink:

@dan still practicing, quick question with attached link/s to tailwind play, good way to share code, how would users share code in Elements.
Can we use the @apply in Elements, simple example at below, only a few under the css tab

https://play.tailwindcss.com/X1LUglCCZE

also my progress, fed up with grids now, roll on Elements

good thing about tailwind play once you change something a new instance is created

```https://play.tailwindcss.com/yAvnOcDPEi```


@dan re wrote the grid version using flex and css, how would this be implemented, 5 box layout , been learning css as well, not sure which is easier now tailwind or css, just need to read up on more complex aspects

https://play.tailwindcss.com/OVP3rr00Pb

Just had a quick play, and yes you can do something similar in Elements…

@Dan really cool thanks for showing, really meant how would I enter all of the code into the html and css area
Also good to see Elements can accommodate 5 boxes, think before you said it was a twelve grid system, might have misinterpreted

Here we go, in the video below I created a custom Element and pasted in your code…

Ah well… those are just flexboxes so you can create as many as you like. I have the wrap items option switched on, and the content of each one was set to 250px.

Ideally you won’t need to write code in Elements, you’ll just use the built-in tools to build your layouts!

Anyway, hope that helps and shows how flexible Elements will be :smiling_face:

1 Like

@Dan thanks for that demo, really easy, can’t wait to build some sites, I agree no need to write code, but I wanted to learn tailwind and css (after I started learning Tailwind), waiting for Elements just gave me the incentive. Hurry up release!!! :grinning:

1 Like

Yeah, that’s great. I think it’s really useful for everyone to learn a little HTML/CSS, even if they are using a WYSIWYG builder!

1 Like

At what point do you realize you have a completely different … element … rather than a “global”?

My use of “globals” is for wider scope access to the same object. By declaring it a global, but then changing everything about the object in each situation, it seems you’ve lost your advantage.

For example, one measurement is to “count the keystrokes (or clicks)”. In order to modify these objects, it seems you’d need just as many actions whether they were two instances of a “global” that you modified, or just two different objects in the same category.

I do understand this was a demo of what could be done and in “real life” you may only want to change title text - perhaps keeping the same graphics scheme for all the similar pages.

Looks like the demo was a success in that it makes me hungry to put up a basic web page (or two, or three - home and two sub-areas). So it’s good to show the features’ powers, but I hope, when Elements is finished you will have plenty of “Your first Web Page” tutorials.

One aspect that doesn’t get much mention is color scheme selection with “color blindness” in mind. Once I created what I thought was a great app with cool button and text colors. But when I showed it to my “focus group” (three friends), I was informed that what was to me states differentiated by color, to someone who was color blind would just appear all gray.

1 Like

I suppose this can be true. But as a designer, it gives you a place to start. If you change it all, then when you change the other global areas, nothing will change—so no harm, no foul.