Matrix - documentation about site layout best practice

(Serge) #1

@Bart

We have a site here that has been designed by Squiz and I’d like to get an idea why this has been done this way, it seems so strange:

  1. There are two site assets (why?)
  2. Some of the nested pages are sitting outside the site asset (why?)

2018-05-29_13-06-27.png1920x1094 79.1 KB

This seems rather convoluted (spaghetti), so clearly, there is something I don’t understand here, some underlying reason why it has been done this way and I assume it is rather important. Could I please get an explanation (as there are none online) as to why it has been done this way so we can start doing the right thing.

Thanks

(Serge) #2

Also, how are we supposed to use this?

https://matrix.squiz.net/resources/templates/system-templates

… a .tgz … export.xml… now what? Is there an import feature somewhere in Matrix?

#3

Hey
This is just separation of content from design. Site designs can be used for multiple sites, so anything global is separated under a design site. The site itself holds the content. The 3rd separated area contains configuration options for a specific site. Generally this includes anything you don’t want to have a URL or want to control access to eg. your editors don’t need to see this stuff.

As for the templates you use the import assets tool:
https://matrix.squiz.net/manuals/tools/chapters/import-assets-from-xml-tool

(Serge) #4

Yeah but that is not the case here. They have done:

Site asset #1: Better Work Designs
Site Asset #2: Better Work

… A site reserved for the design of another site (exclusively, this is quite clear by the name) is not something global that is going to be reused. So that does not make any sense and therefore the wrong way of separating assets. Why aren’t designs part of the external folder that doesn’t have a URL as we don’t want content editors to modify designs anyway. And why is this folder outside the site, can’t we just not give it a web path and remove permissions for content editors?

(Serge) #5

2018-05-30_9-30-56.png358x706 25.4 KB

Ok, that’s what you have in the matrix documentation as the best practice asset layout for a site.

Do you have any tutorial on how to use this adequately? Some kind of tutorial on how to build various site layouts using that arrangement?

Basically; where is the doc about how to use best practice layout adequately?

#6

Bart talks about some of the decisions in this presentation but I’m not sure if it is documented to the level you are looking for.
https://matrix.squiz.net/resources/media/squiz-summit-2016/squiz-matrix-implementation-tips-and-tricks
I guess one of the big reasons comes down to consistency? Yes there are dozens of ways of achieving the same thing, and in complex installations finding things in the same spots helps minimise maintenance and support.

But just a couple of examples from personal experience include:

  • If you put nested content assets under the site they can inherit designs/permissions/webpaths and be inadvertently discovered and viewed as a page of their own.
  • A lot of the time you will be cascading permissions/workflow/metadata down from a site level and don’t want these applied to site assets. Cascades can take a while so you don’t want to add to that unnecessarily.
  • Site content editors don’t need to see half the stuff (and you may not want them accessing it) - this gives you more control and they can focus on the content.
  • Makes developing and implementing new designs easier if the old one is distinct.
  • Some things just don’t make sense to be under the site eg, paint layouts, schemas, an asset listing that only works when nested with dynamic parameters. You logically want this stuffed grouped but not clogging up your site IA.

So even if there is 1 site for a design it makes sense to separate them.

I’m not sure if design assets themselves require web paths but the images/js/css that make up the design do.

HTH

(Douglas (@finnatic at @waikato)) #7

There is some sense to the site layout you’ve encountered - we also had the surprise and have had some discussions since which have somewhat addressed our curiosity.

It’s not entirely a great solution for us, but I can see some benefit of having design resources in a related site/folder (a site makes them accessible via Edit+ if needed) to keep them nearby in the asset map, but out of reach of content editors and others who may not understand what they’re for.

(Of course, that’s not going to stop me creating an asset listing specific paint layout underneath the asset listing where it’s directly accessible and I don’t have to go and find it and have a messy asset map as a result.)

Best to strike up a discussion with Squiz staff directly I believe.

(Tbaatar) #8

In addition if you have more than 1 domain / website under the same Matrix build (and from my experience I have worked with single matrix builds with over 10 domains) then you don’t want to apply URL path to the root Design/Media folders as you will end up with 10 different URL choices when working with Media Files, even worse if you currently use both HTTP/HTTPS.

Therefore it is best practice to keep these files under domain level by separating it with different site earth and breaking down the Template modular components that can be easily be managed. Also, like boiler-plates/frameworks if you don’t need some sections/folders just remove it.

(Serge) #9

I definitely agree with that. Too often there is this idea of “re-usability” or “centralising components of same type” but it just makes a mess.

One way of addressing this would be for Squiz to develop asset symlinks so we could put shortcuts to specific assets where it is relevant. Especially since the Matrix search function is appalling.

(Serge) #10

Well it’s the Matrix forum, I’m assuming they are looking at the posts.

(Serge) #11

Yes I’ve seen that one but that’s hardly documentation on best practice.

We should have something that:

  1. Explains the layout as provided in their project xml file
  2. The rationale behind the choice of placement of each asset (speed, security, ability to quickly find relevant assets, etc), not just “I put it there because I’ve always done it that way”.
  3. Example of complex sites, both as a tutorial and as the xml file so that can be imported and played with.

It would be good to get something somewhat standardised.

Squiz?

(Bart Banda) #12

I’m not sure, as I wasn’t part of the implementation team that did this work. Maybe contact your Squiz account manager to try and get some help from them to try and get the background and context around this particular implementation?

But like others have said on this thread, having two separate site assets like that is often done to separate content and design. It makes it easier to do things like applying workflow, permissions, designs, etc from a single root node.

As bkelly said, you can use the XML import tool. A few step-by-step instructions here: https://matrix.squiz.net/resources/templates#import-instructions

In regards to providing some more contextual documentation around that site structure, it is something we want to do, but we are actually planning on releasing an updated version of that “site boilerplate” as part of the upcoming 5.5 release, one that is mainly structured the same, but with less default assets in the import. Once we do that we’ll aim to have some additional documentation to follow.

Again, it’s just a recommendation, not a requirement to get the best of out the software. If there are other site structures people have used with great success, we’d love to hear from you so that we can keep improving this template.

Hope that helps.

(Serge) #13

@Bart

That just gave me an idea. What if assets had a default meta data called “info” that would contain some explanation and would pop after a couple of seconds of onMouseOver, basically making this contextual documentation. Of course this could be turned off.

#14

Squiz has done this arrangement for quite some time, it does seem to work in a practical sense when maintaining models over a period of time. From my view some of the reasons may be:

  • Even though there may not be a strict technical separation of design and model (by that I mean the design is not fully re-usable across sites due to coded asset references) it does encourage a logical separation. Admins/designers should think in those terms as much as possible.
  • Matix does have a habit of cascading things, especially permissions/workflows/metadata so helps you avoid mistakes in this area.
  • Helps separate user roles, is you do have a lot of non-technical content users vs admin/design editors it’s easier to arrange permissions
  • Can be an advantage if importing, exporting or upgrading designs (creating a second design them swapping over).

As for the assets that are outside of the site assets altogether the normal reason given is if they are under a site they are given a URL and therefore form a page. If you put them under the site try right clicking and previewing them, it will work you will get just the isolated nested asset showing. I believe that there have been cases when Google has found these assets and they have appeared in a search and the public have found those addresses.

Just some thoughts.