Folders vs Documents [was re: 0.9.5 Public Beta 3 support]

[Guest]

Welcome, Guest. Please login or register.
Did you miss your activation email?

1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Andy Ayre]

Rev 1581. Folders switch to appearing as documents in manager tree.

1. Create a folder -> tree refreshes and shows folder. Expanding it shows no documents.
2. Add a document and place it in the folder
3. Delete the document
4. Purge the deleted documents -> tree refreshes and the folder now switches to appearing as a document

Andy

[sottwell]

That's not a bug, it's a feature  No, really, if a folder no longer has anything under it it's automatically switched to being a document.

[Andy Ayre]

That's not a bug, it's a feature  No, really, if a folder no longer has anything under it it's automatically switched to being a document.

OK, how about this: I want to use @INHERIT for some template variables, setting the TV to what I want for the folder that contains the documents.

1. Create folder
2. Edit -> default template is Regular but I cannot see the TVs for it
3. Switch template to (blank), choose No - I don't want to change it
4. Switch template to Regular -> both content field and TVs now show up

So each time I want to do this setup I have to go through these steps. I guess it would be quicker just to create a document rather than a folder and then use the docment as a folder. But how do you explain that to a client, that documents switch into folders and vice versa?

Andy

[rthrash]

OK, how about this: I want to use @INHERIT for some template variables, setting the TV to what I want for the folder that contains the documents.

1. Create folder
2. Edit -> default template is Regular but I cannot see the TVs for it
3. Switch template to (blank), choose No - I don't want to change it
4. Switch template to Regular -> both content field and TVs now show up

So each time I want to do this setup I have to go through these steps. I guess it would be quicker just to create a document rather than a folder and then use the docment as a folder. But how do you explain that to a client, that documents switch into folders and vice versa?

The default behavior of creating a folder technically shouldn't allow for making any content or setting TVs. I find it personally not right and confusing as well. What you've managed to do is to find a workaround for this.

In fact, this is the very reason why there is no create a new folder icon above the tree menu. My reasoning is that if you need a folder, just set the checkbox. I'm not so sure we shouldn't remove the dedicated "folder" page types from the next version which removes another option (less to think about) and could eliminate a potential point of confusion.

A folder is JUST a page that contains other pages.

[splittingred]

In fact, this is the very reason why there is no create a new folder icon above the tree menu. My reasoning is that if you need a folder, just set the checkbox. I'm not so sure we shouldn't remove the dedicated "folder" page types from the next version which removes another option (less to think about) and could eliminate a potential point of confusion.

A folder is JUST a page that contains other pages.

I wouldn't remove it - sometimes it's beneficial to "flag" a page as a folder, for navigational and structural purposes. If you're going to go that way, it might just be better to go one step further - get rid of pages being able to hold other pages, and be able to actually create real "folders" that hold pages, with the default loading of a folder going to the index.

Of course, the latter introduces all sorts of navigational schematic debates... 

[rthrash]

The flag would not be removed by any means. Just the dedicated/minimal "create a folder" menu item/action page.

[Andy Ayre]

A folder is JUST a page that contains other pages.

I understand exactly what is going on, but I think most non-technical clients who will use MODx for day-to-day managing are familiar with folders and files on Windows and would be confused by this. 

I think real folders where you can set default values for any TV would be better. For example, suppose I have the templates foo and bar, and foo has the TVs foo_tv1 and foo_tv2, and bar has the TVs bar_tv1 and bar_tv2. If a folder allows setting of default values for all four TVs without specifying a template, then the folder can contain documents using both templates and they can all use @INHERIT.

Andy

[rthrash]

Then based on that suggestion we should remove the folder checkbox from the document editing page. I think this is going to lead to a lot more confusing and frustration in the long run. Training a person what the checkbox for folder is/does takes less than 60 seconds.

To use the Windows analogy for folders is also a potentially dangerous road to go down. A web site is not your local filesystem. Windows folders DON'T contain data/content. They are simply hierarchical storage containers devoid of data (ignoring metadata and special circumstances like .app folders in OS X, but typical users don't know about that stuff anyway).

A MODx "folder" can contain content. So is it a folder, or is it a page?

The more I think about it, the more I'm in favor of getting rid of the folder icon entirely, and just letting the indentation indicate a document heirarchy and structure... like a sitemap. That would make the "is folder" checkbox become "is parent". And with the new skinable manager system in the next release, if you absolutely must have folder icons, you can easily do that with a custom manager theme.

[Andy Ayre]

The more I think about it, the more I'm in favor of getting rid of the folder icon entirely, and just letting the indentation indicate a document heirarchy and structure... like a sitemap.

That would work as well.

Andy

[rthrash]

Based on an extended chat with Jason and this sub-thread, here's what I think makes the most sense for 095 (the next release):

• Loose the new folder action page entirely for now (and the icon too... see custom theme stuff above for folder-icon devotees)
• Change the "is folder" label to "is container" (a container is just like a folder, only it shows whatever content you put there (or don't) ... even blank content)
• Loose the logic that auto-transforms a container/folder back to a page if you empty a folder/container

After the 095 release, we could possibly add a true folder type:

• by default goes to the first child content page
• can optionally have a specific "index" page set, which would just auto direct to a specific page
• permissions would allow you to turn off this type of content for anyone but admins/super-users. In fact it should be off by default for anyone but admins as it's more of a technical concept for dev-types.
• you could set default TV values on folder types for @INHERIT use without having to jump through hoops to do so.

[Andy Ayre]

Why "container" instead of "parent"? The former is another name for folder, the latter describes a document-only hierachy IMO.

Andy

[ZAP]

Interesting discussion... this is something I thought about a lot when I started to use MODx, but haven't really revisited since then. Each time I introduce a new client to the system I do have to explain it, however. And I usually have to go over it more than once, since the folder metaphor isn't entirely accurate (as Ryan pointed out), and people don't initially realize that folders ARE documents and can be viewed as such.

Usually this means that I end up either deleting extra documents that people make because they thought the folder needed an "index" page as well, or just creating the whole structure for them and then explaining it to them.

But then the question is, "how can we make it more clear?"

I definitely agree that the "Create Folder" menu item should go. There's no more point to that then in having a "Create Published Document" menu item. I think that the more streamlined the menus are, the quicker people will get the hang of it.

Personally I would lose the folder checkbox as well, since it doesn't seem necessary at all. Got documents under it? It's a "folder". No? It's not. And if we're going to shift from the "folder" metaphor anyway, then this checkbox will actually be a detriment ("Is Parent?" seems a bit obtuse to me). I don't know of any reason that it might be necessary to create or view "folders" that are empty, but perhaps other folks do.

So I guess I also would advocate for the "sitemap" indented method of displaying "folders", and I'd also completely remove all references to them (including the Is Folder checkbox). Simpler is better, in my opinion. The fewer options and checkboxes that a new user has to take in, the better (especially if they serve no necessary purpose).

Next step: Can't we combine weblinks and documents as well?

[Andy Ayre]

Yes, if a document has children added to it then it automatically becomes a parent, otherwise it isn't a parent.

Andy

[rthrash]

You can actually do some things with the isFolder checkbox in snippets. I've used it before to create category menus and things like that, so it is a beneficial bit of metadata. It could also be used (if sticking with empty folder icons) to denote an area which needs additional content, but it's not quite ready from a client. A "section placeholder" so to speak.

Likewise, isParent isn't accurate either. A parent by definition has children. A container can be empty (as can a folder).

[Andy Ayre]

Section placeholders is what I was trying to set up when I found them reverting to documents. I didn't mention it because I wasn't sure it was a valid argument.

Andy