There's several simultaneous discussions going on about content types / node types - the terminology at that high level, and in terms of how we explain particular node types like "book page", "page" etc. and individual nodes/posts. So I'm starting this to try to draw some of them together.
'Content types', 'Create content' - along with 'post settings' and other areas where we use node, content and post interchangeably - also came up as a major, major issue in the formal usability testing at UMN, some examples are in the Drupalcon presentation slides if you haven't seen that yet.
The three discussions that prompted this are:
- Naming and description of node types can be much less confusing
- Content types rethinking (which I'm trying to redirect back here
- What word should we use instead of "node" in end-user interface and documentation?
- And fwiw, Story is now Article in D7
Probably a bunch more around and I'm sure there's some really old 100 post long issues as well which if someone finds would be good to reference.
Comments
Re-thinking node types
I posted this earlier here: http://drupal.org/node/233222
I think we need to change content types to node types because the settings in them are all about how the nodes are displayed and handled by the system, not actually about the type of content in the nodes (which would be rather a semantical thing).
I think the blog node type needs some re-thinking. I think it would be great to be able to add any type of node to a blog. Instead of making a separate node type for blog posts, they should have a checkbox whether or not they are on the /blog page of the author (actually much like the book module, but simpler).
Polls should be a separate node type, no doubt. The functionality of polls is so different from other types. Same for 'Issues' like they are used on this site. However, I am even wondering if it would make sense to make forum topics a custom content type (much like what happened to book pages in D6). There is nothing about them that makes them fundamentally different from plain node types, just the framework around them. I think the forum is more defined by the way the topics are structured than the way the content type is designed.
Thinking this through, a few examples:
Let's make a node/3. The node type of this one is a, well, basic node type. Apart from that the node has data in the database table for book which says that it does not have a parent in the /book outline if the book module is enabled. Also it has value 0 (FALSE) for the field 'promoted to author's blog' and also a field in the forum table saying that it is a forum topic in the forum/3
The forum and book data is easy to handle (parent number it the respective table). I would suggest to add a 'promoted to author's /blog' in the workflow settings when the blog module is enabled and have a new field in the node table for this value.
.
Sorry for my simplistic view of the way Drupal works, please correct me if I am wrong anywhere...
I think we need to change
This is an important point. I use news / history / library content types on one site to differentiate between three sections - however the structure of the node types is identical - it's just an easy way to filter in views - they're definitely all 'articles' and there's massive overlap (we have history articles about last year, and news articles from four years ago). Other sites use taxonomy to do exactly the same thing and both methods have their advantages and drawbacks.
The blog module is very old, and predates views. If you're using Drupal for a single person blog, you'd never switch on the blog module (which imo is a usability issue in itself), and the functionality is easy to replicate with views and a bit of breadcrumb trickery. I think I'll start an issue for this :)
I agree with this. The book module got a major cleanup for D6, forum module had some improvements but architecturally it's very much 'old Drupal'. A few of us have plans for forum module in D7 (http://groups.drupal.org/node/8598) but there's some difficult issues to deal with on that.
OK so for me there's a few
OK so for me there's a few issues (and they apply to taxonomy as much as nodes, although the user interface text got completely gutted and rebuilt for D6 so hopefully we can just tweak it for D7).
Previous attempts to make terminology less jargony have led to inconsistent usage of different words to mean the same thing. Whatever we use, it really ought to be consistent. Just as importantly, simple words like 'Content' and 'Story' can be just as jargony as 'Node' if they used in non-standard ways ("A story has a beginning and an end right?" "Am I creating content or am I creating a content?") - they still have to be explained in the specific context they appear.
At the moment, node only appears in a couple of user facing places in drupal - at admin/help/node... and in approximately 50 million urls around the internet (not all of those are drupal sites, but most are). Those who'd like to completely strip it out of Drupal altogether should bear that in mind.
Despite attempts to hide it, new users are still finding out what a node is, and quite like it as a concept, so personally I'd like to resurrect it in the UI a bit. It's an essential drupal concept which is pretty hard to avoid, and which which post/content doesn't communicate. Better to learn at the start (with much better inline help and a glossary to make that process easier) than have to learn the 'easy version' once, then unlearn it all again a few weeks later because we lied to you.
I think 'node' should definitely be used to refer to individual nodes, I'm less sure about 'node type' - partly because I automatically use 'content type' now for some reason.
There's also a general issue of confusion between the high level concepts and individual instances - if I create a book page, I'm not automatically creating a book along with it, if I create a 'page' it's not a whole web page, just a part of it. To an extent I think this is a similar problem to node and node type in terms of how Drupal works architecturally.
So...
..
As I've mentioned in other places, I think "node" is fine, as long as we use it consistently (and probably explain it on the front end somewhere). As you rightfully remark, there are 50 million reasons to use "node" in an intelligent way.
As an aside, though I wasn't there for the usability testing, one thing that I took away from hearing people talk about it was the somewhat surprising realization that people did OK with taxonomy and setting permissions. These two areas are perennial favorites for internal usability complaints, however. It may well be that "node" is the same way. Our target audience may just look at go "Oh. OK. Fine. Whatever." while we go "This is too complicated".
// As an aside, though I
// As an aside, though I wasn't there for the usability testing, one thing that I took away from hearing people talk about it was the somewhat surprising realization that people did OK with taxonomy and setting permissions. These two areas are perennial favorites for internal usability complaints, however. It may well be that "node" is the same way. Our target audience may just look at go "Oh. OK. Fine. Whatever." while we go "This is too complicated".
Well I was pretty adamant about changing taxonomy back to categories in 6.x, but also in the back of my head I thought it'd come back to bite us (fingers crossed it hasn't yet!). So yeah I think 'node' is the same thing. As long as something's explained clearly then to an extent it doesn't matter what it's called. Taxonomy has the advantage that you can look it up on wikipedia though of course - there's not quite the 2,000 year background for node types :(
Wikipedia does say this though: "A node is a connection point, either a redistribution point or an end point, for data transmission.", well kinda.
wikipedia is editable ;-)
Hey, check this out:
http://en.wiktionary.org/wiki/node#Noun
"Despite attempts to hide
"Despite attempts to hide it, new users are still finding out what a node is, and quite like it as a concept...." - so true. It's important not to be dogmatic about eliminating jargon. As it turns out, jargon has its own role to play.
And, if help is improved in any significant way with the addition of search, task-based and segment-based explanations, we'll have more opportunities to 'translate' these features to users as well as make them more discoverable. If, for example, a user searches help for "web forms," we could pretty easily explain how content types can help you make web forms and then provide a path for users who care to get a more complete understanding of the functionality.
This might help us to strike a balance between the need to uniquely name features with functionalities that are more or less endemic to Drupal while also meeting a variety of plain language scenarios.
User-bility is for end-users
"Node" is a fine, specific term, for developers.
But many end-users have not heard of a "blog" let alone a "content management", and a more friendly term is required in order to be understood. Since devleopers understand that an approximate term is being substituted, EVERYONE is understood. But use the term "node", and you loose your intended audience: new users.
Approximate alternatives: article, story, content, contribution, submission ("page" is no good, as it could refer to a collection of different contents). My personal perference is "article" which sounds more sophisticated than "story", and more specific than "content" which could refer to other kinds of contributions (eg. events)
Well to me the end user of
Well to me the end user of drupal is the person who downloads it or administers it, up to and including sub-editors. And many users are also developers or vice versa. Visitors to a site don't have to see anything about nodes (including the urls if you use pathauto and global redirect) or even know they're using Drupal, let alone what blogs or content management are - but that's down to the person setting up the site, Drupal can only make it easier to customise and try to provide a sensible framework to operate in.
Article is currently used (instead of story as of two days ago in D7) to mean a particular type of node - so the concept of adding an article to a site is there. When discussing node types it's really about the administrative interface - and saying that you could have 'article types' would just confuse things there. Is a video an article? An image?
I don't see the trouble with
I don't see the trouble with "node". It's shorter and sweeter than more typical developer-centric terms like "object". The end-user will have to gain some familiarity with it anyways since it appears in URLs (out-of-the-box at least).
I've built several sites where a content page consists of multiple nodes, and various relationships between nodes. So it's easier to talk about nodes when that's what you mean. To me content is a more amorphous construct and nodes are the building blocks.
Agreed
As a newcomer to Drupal I had zero idea what "node" meant. It's simply not obvious from the non-Drupal meaning of the word. As someone who's generally pretty knowledgeable about these things I picked it up pretty quickly, but general users of my websites have no way to know what "node" means. No, I don't have to reference it that way in anything I write, but it's still in the URL which means it's not a developer-only term.
Honestly it would be best if the term "node" was rename-able in the system or strip-able altogether like with Clean URLs.
For my users, I've been using "content" to mean anything that appears on the site and "post" to mean any content that's not a comment. That seems obvious enough to me.
The question we should ask is not "is there a problem with it" but "can we make it better." And the answer is yes, we can: obviously there's a problem to some extent or we wouldn't be having this discussion.
First, let's remove 'Post'
First, let's remove 'Post' from the terminology here. It's meaning is somewhere in the middle between content en content-type now. Post-settings in the admin lets you set number of nodes on the homepage, teaserlength, preview option. I suspect Post is the pre-CCK umbrella term for the basic core content-types Story, Page, Book Page, Forum etc?
I think node should stay. We won't find a nicer, sweeter or shorter term for the general concept of a Basic Drupal Content Thingy. Anything more concrete and it will get confused for a content-type. We need to have a word for this concept and link it to the idea that all nodes together == the whole of your content-items ('pool, 'liquid'). Yes its a word you may have never heard of before, but I really really think that a Drupal user (the contentcreator/admin kind, not a site visitor) can be taught this new word and concept.
So how to make a good distinction between the node soup and the different crispy bits in there that give users a handle on article, page, image and mygreatcck node-types? Well exactly that, give it shape, form, make it concrete, solid.
Media and Media-types? if you try to be very literal and use 'photo' with a big glossy icon of a picture in a frame or a newspaper frontpage for your custom News nodetype you'll run out of sensible options for complexer multifield types. It's a viable approach though, that can cover a lot of the basic types including things like events, og groups, etc.
But what would be the best umbrella term for all of these?
Containers? Pour nodesoup into containers of different shapes and forms.
Forms?
Hmmm, forms… wasn't that a word the users in the testlab were desperatly looking for? (maybe influenced because of wording of the tasks?) But still. Forms.
Isnt that the ideal candidate for the basic concept of a content-type? For users/admins, that is what they are building and filling out all the time.
node and form
nodes and forms
nodes and node-forms
Of course there's lots of other htmlforms in Drupal that don't relate to nodetypes at all, so we cant marry the two completely and everywhere, but there's a nice overlap between 'Shape' and 'Webform' in this particular context, no?
Maybe silly and too obvious wordplay for native speakers? In dutch it's Vorm' and 'Formulier' so I never really had them overlap like that… :-) I really think it works well though:
nodes and forms
node and node-form
content and content-form
Hmmm.
"node-form" is an interesting idea.
/me goes off to think about this further.
...
Anyone else notice how the only word anyone can think of other than node is "content"? That's what it is, really. "Node" just means "content," and everyone already knows what "content" means, so why make people learn a new word?
But it's not just the creator/admin that has to learn what "node" means -- it's every single user of any Drupal site, because URLs are named with the word "node" in them.
Node!
Content is not the same as node, a node is an entity of content in Drupal! The beauty of the word is that it is neutral and generic. Anything can be a node: articles, forum topics (the main content of a forum topic is in the comments not in the node), polls...
My solution is this one:
From D7 on the default address of a new node will be /n/add .
In other words: change node in the url to n and users won't even have to think about it!
Imagine I'd give you a link to michaelkillian.com/n/5 :-) not confusing at all. n could stand for number for the visitor, which is fine. As soon as you administrate you learn that it stands for node and the whole concept of node is fine!
Also, it wouldn't be too hard to have both /n/5 and /node/5 link to the same page (for people who are used to node). This is what I call a usability improvement. Changing as little as possible and making things less confusing...
You can change that yourself
You can change that yourself in D6 using custom_url_rewrite_outbound() - change all node paths to 'n' 'article' 'foo', anything you like.
custom_url_rewrite_outbound()
Where do I find custom_url_rewrite_outbound()? I wanna do it to all my sites straight away!
Do you think it would make sense to ship D7 with a checkbox to display node urls as /n or /node (outbound of course, inbound both should work!) That would be a usability improvement IMHO!
You can find all core
You can find all core functions on api.drupal.org - this one is unusual in that it gets placed in your settings.php rather than a module since it has to operate before modules are loaded.
Displaying content at both /n and /node would lead to duplicate content which is a search engine black hole so I don't think you'll ever get that in - especially considering you can do it with pathauto in about 2 minutes (including installation) and about 10s in custom_url_rewrite_outbound() cut and pasting from the api entry.
awesome, thanks!
it all makes makes sense, I just wish it would be easier to find out about this kind of things... I would have never found out if you hadn't told me that!
Many thanks!
Good start,
But the problem with "content" is that it doesn't noun very well. (nor did "noun" verb very well :)
First, you click "create content",
Then you decide what type of content you want to make. (good so far)
So you make a new content. (um?)
Then all your contents are listed in the home page. (also true, but not the intented meaning)
If you want to choose 2 contents to promote, go to 'content management' and check the box next to each content. (Now we are getting silly)
Some contents are newer than other contents. the newer ones wil be listed at the top (arg)
To delete or edit a content, press 'edit' when viewing the content. (OK, I'll stop)
I could possibly live with "entry", although that's still a bit bloggy.
iantresman is trying to get the terminology dumbed down to the point where someone who cannot comprehend or even learn the words "content", "management" and "system" will not be forced to think. Using small words for big ideas is intellectual bigotry. An image (or should we call it 'picture'?) is not an article. Neither is a 'product' (or should we just call that 'thing'?)
The folk that keep thinking of Drupal only in terms of a blog need to realize that the system is bigger than that. And Taxonomy has a much richer, and more accurate meaning than just 'tagging'.
Two words. Both are, if not common among uneducated people, at least existing, dictionary words.
The word "node" didn't come from the coders, it came from Information Architecture. Someone who's building a site should at least be aware of the concept of structured information, even if they don't have to be an expert.
Non-web folk are not expected to look at the URL. Web folk who care can add pathauto and instantly have their url-pages named pages, their url-blogs named blogs. That's a small issue.
I personally may not be clear on the difference between a cow, a bull, a steer, a bovine, and a heifer, and would probably just use the generic dumb-word "cow" most of the time. BUT if I started to get involved in farming for like more than a day I'd probably figure out pretty quick that there's a relevant useful distinction. And continuing to insist to the guys that know that : "They are all just cows, why don't you guys just call them cows? You trying to be clever or something? Nerds!" would be a pile of bull****.
iantresman may believe his dad is beyond learning, But I have more faith in people. Ignorance, I can forgive, as it can be cured by education. Willful ignorance and a refusal to learn... I have no time for.
Besides, where is the "problem" seen? On a system configured by someone who knows what they are doing, the non-admin contributor or editor need never even need to see or hear the word "node". I've been supporting a content editor for 6 months and I can't remember even having to say the word when all we are talking about is Products, Images and Pages (never posts or articles, however ;-)
Documentation can always be improved. That's why we have these discussions. But the point of documentation is to tell people things they don't already know. That sometimes means introducing new concepts!
.dan.
Yo!
Totally agree!
Node = node.
Content = content.
If you don't want to learn that, then don't build Drupal sites...
Great post!
It's been a while since I was new to Drupal but I don't recall ever being bothered by "node". It doesn't take that long to pick up Drupal terminology. I think it helped that this was my first CMS so I didn't have any preconceived notion of what things should be called but, even if I had, it's not that hard to learn a new word.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
That was a great post, dman.
That was a great post, dman. I appreciate you thinking about how these words are used in practice, because otherwise, it is often difficult or impossible to use them intelligently in a sentence. And, it gets even tougher when you have several such words and have to construct sentences somewhat consistently, as in the content type descriptions.
The problem you point out with "content" is very real. We have a similar issue with the oft-used "post", in that people easily confuse the noun and the verb forms.
And oh: http://en.wikipedia.org/wiki/Cow#Types_of_cattle (I grew up on a farm and vividly remember my dad and older brothers teaching me the permutations of cattle naming.)
...
No.
First, you click "create content." Then you decide what type of post you want to make. Then you make a new post.
All the new posts are listed in the home page. If you want to choose a post to promote, go to "content management" and check the box next to each post. ("Content Management" should be changed to "Post Management" unless it includes comments.)
Some posts are newer than other posts, and the newer ones will be listed at the top.
To delete or edit a post, press 'edit' when viewing the post.
So you see that the word "post"--which is very widely used around the 'net--is the new word for a node, and "content" means everything. You can say "when you're viewing the content" and that means "when you're viewing the page with the post and its associated comments." Not only is that more descriptive and accurate than "node," it's also better known and easier to pick up.
Post is fine, and we
Post is fine, and we certainly use "post" and "posts" a bit in Drupal, as in "Post date" or "Post settings" or "A blog entry is a single post...".
The problem here is that we also use it like "Post new blog entry" or "you don't have sufficient permissions to post this type of content".
How bout some love for submit?
"Submit new blog entry", "...permissions to submit this type of content" "Submission date" "Submission settings" "A blog entry is a single submission"
I think submit could take the place of post rather nicely. Almost the button you push at the bottom of forms to add a new node is the "Submit" button so I think the terminology flows. Plus there's no Post, Posts issue because the word changes from submit to submission or submissions so there's a difference in word tense between something that needs to be submitted and something that is a submission.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
Not submit any more. We
Not submit any more. We standardised to 'Save' everywhere in D6.
Sorry bout that, haven't
Sorry bout that, haven't looked through D6 extensively yet. I'll still stick by my comment though that I think Submit would be more flexible in this case and would standardized terminology in a way that could be easily understood by a lot of people. It also verb-izes well :)
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
I always find 'create
I always find 'create content' to be a little unnatural. Submit works (and gets past potential confusion with creating a new content type), although maybe it's tied in to particular kinds of web sites too much.
Save node!
Ok, so I post in the forum but it's not a post because it's a comment and posts are nodes? I don't like that at all.
I don't get this sudden movement to rename everything in Drupal. Node is fine. It's nice and abstract and covers things that aren't posts, like user profiles. Sure, when you learn Drupal you have to learn what it is. So? When I got into photography I didn't know what an aperture was, either. I didn't expect people to change the name to "hole" so I didn't have to look it up.
-1 on changing node to anything.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
The idea is to lower the
The idea is to lower the cost of entry into Drupal in all ways. Lowering the learning curve through the use of good terminology system wide can help users logically flow from one area to another. I have no problem with node if things are standardized system wide but there are other ways of referring to what that is. Content, node, page (as the initial content type) can all be confusing to people as to how those are different (or if they even are...).
A node is a piece of content
A page is a type of node
A page is a piece of content
The problem isn't the word node (imho) it's the fact that this relationship isn't clear. I think we should standardize on node as the lowest level (as it is now) but then change the descriptors and verbs associated to the term node instead of blurring what a node is with other nouns that are (or can be) similar in meaning.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
I like "submit"
Michelle, photography was not trying to attract potential users. Plus, an aperture is not "just" a hole. Drupal is trying to attract users and make it as easy for them as possible, and frankly, a node is content, it is a submission, and it usually is a post.
...
"photography was not trying to attract potential users"
That was just an example. The point is that when you are learning something new you should expect to, well, learn.
"a node is content, it is a submission, and it usually is a post."
So let's call it a node. Then we don't have 3 different words for it. Especially because the reverse isn't true.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Nodes imho should stay. What
Nodes imho should stay. What pages are to books, is what nodes are to websites afaiac.
I think of node as a capsule of content than can also contain smaller capsules of content. (I think d.o's description of node is similar.) Individual nodes can be displayed (or downloaded) and/or parent nodes containing child nodes can be displayed.
Rather than change node, it would be more sensible to provide a clearer and easier to understand description of what a node is and post it on the first time installation screen so that first time site builders have a description of what a node is (instead of having to guess, google or search d.o for the meaning of the word 'node')
+1 on renaming content types into node templates
post?
i can see a very sophisticated discussion going on here. but as a new user, i cannot find anywhere to post apart from sending replies to posts. many thanks for any help on this!
One alternative to 'content
One alternative to 'content type' that came up in the testing was 'template', which I like. What is the difference between content types? Generally it is just a difference of what fields are included or what order they are in -- their template.
Form is another option, but that implies that it affects only user input forms, when it is also about having different ways to display the data. So I think template (or maybe node template) is the most clear.
Template is a good word. It
Template is a good word. It might get confused with contemplate among very hard-core Drupalers, but I don't think that is enough of a problem to avoid using it.
node template sounds good
It covers a lot of the issues with 'content' and communicates the reason to have different content types better than 'type' - one of the issues with the default 'page'/'article' distinction is that you can add comments to a page, or take a story off the front page if you're an admin - and template better communicates that lots of settings are defaults that can still be changed at the level of individual nodes.
I was a little worried about confusion node.tpl.php files (and contemplate module) - but really CCK drag and drop + display fields, views display plugins, panels 2 and the rest are making an incursion into that area anyway from different angles - so some terminological connection the UI generated display and the theme layer display might even be a good thing :)
I like template well enough
I like template well enough to roll a patch. If it gets shot down, then oh well.
I'm thinking about replacing "content type" with "template" though. Catch, you think it needs to be "node template"? My only thing with that is "node template" will require getting "node" reaccepted into the UI. "Content template" does sound too much like contemplate, which leaves "template". And, there's the underlying question of whether we'd have to change references to "node type" and friends in the internals to "template" as well. I was thinking just try for UI changes now and see how far that goes.
template/theme...
I reckon 'template' by itself will get confused with 'themes', which would be bad.
I'm personally not worried about 'content template(s)' getting confused with contemplate.module - more people use core, those who get confused will get over it quickly (because they'll presumably already use contemplate module and know what it is) :)
We could go for content template as a first round patch, then try content > node separately? The latter is going to be a long issue with a lot of FUD on it, the former might</em be straightforward.
If you roll a patch, I would
If you roll a patch, I would also move it into the Site Building area and out of 'Content Management'. That way 'Content Template' won't confusingly show up in the same place you see 'Content'.
Plus 'Site Building' was the
Plus 'Site Building' was the place everyone was looking for this kind of functionality :)
Please take a few minutes to look at my proposal
Please have a look at my ideas here and tell me what you think:
http://drupal.org/node/232294#comment-767438
I can back your logic with a use case
I know that in our department we've created a way of visualizing books a bit better then past methods through icons and we ended up using a lot of "folder" node types which essentially just were used to group / order things in the hierarchy of a book. They were strictly for structural purposes and stored no content on their own so I completely agree with the folder type. I think it's important to move towards the file/folder directory structure terminology because that's the lowest common denominator with most people. Most users are farmiliar with a mac/windows environment (of whatever flavor) and so if you use a computer the concept of folders and files comes naturally to you. It could be strange though if you have physical file folder structure and "book" based, database structured content. Got a few comments to your terms below:
* content type >> node type (template? I'll think about it!)
--Using the word node here indicates that a node is the lowest type of object which, if that's the case, then it is. I'm still torn on the idea of making people learn what nodes are. Admins / most of us in this discussion will know what a node is but I've had to explain it to every end user i've worked with. I think we either need to eliminate it completely as a word OR get rid of everything that is similar to node but isn't (like content).
* Article >> Article
--Why is there still an article/story/ any packaged content types with the system other then the page node? Just an aside really... but I do think that article makes a lot more sense as the initial type then "page" or "story" as they currently are. Article is something I think people can relate to. Based off an earlier argument it also makes sense in other contexts ("create new article", "promote article to front page")
* Page >> Static Node
--I think this should be called article for reasons just listed above. Also then you get into the argument of "if there's a static node, where's the dynamic one?". I think the word static should be distanced from drupal as much as possible.
* Book Page >> Article (or sub-type of Article)
-- Page, article, book page are all the same type imho.
* featured to the home page >> promoted to the front node (prominent as the star option in Gmail when editing specific node types)
--I think you need to drop the use of node in this instance. It should be more of "promote [content_type_name] to the front page". Possibly removing the word page from that phrase but I don't know how you refer to the front whatever unless you call it a page unless maybe you call it "site" so "promote [content_type_name] to front of your site"
* book(s) >> folder(s)
--I think you create folders or organizers as the way of organizing (dur) content in the system. I agree with above comments that "book" is a bit antiquated from what it's original purpose probably was because most people don't think of their content as a book. I've structured most of my websites in a "book" format though the word book doesn't make any sense. Maybe everything can be part of a folder/organizing structure and it's just a permission that lets people structure that article/page/whatever instead of it being a separate content type.
* outlining >> filing
-- Read previous one.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
Yo! thanks for the feedback!
I like your reasoning and agree with most of it.
Actually, I wrote this before I heard of the template idea, and now I think of it I am quite fond of the concept of templated instead of content/node types. The difficulty with managing these templates would be that they can differ in two different ways: One is the custom field (CCK, and I'd like to include the poll type as well here) distinction, which makes different types imcompatible for converting, and the other one is where the data fields of the node are the same, only the default settings differ. I find this a hard nut to crack: how to organize these things? Because I think it's very sad that it's not possible to change the content type field of a blog entry to article without having to use an unreliable contrib module or tampering in the database directly. Anyway, that's just my contemplation.
I think we need to work towards a flawless CCK integration where the end-user has full control over adding and dropping custom fields and it's easy to decide whether a change in content type would cause too much data loss.
Another possibility (probably added to the previous one) is to not have content types at all, so that in a way every node is has it's individual custom fields independent of type-related nodes. Every individual node is customizable with CCK... That would be taking the concept of templates really serious! So editing a node does not only involve filling in spaces, but can also involve creating these spaces for the individual nodes.
Thinking this through this would mean that we actually un-merge two essential parts of nodes: the structure and the content. It would still be possible to add custom fields to all nodes of a particular kind, like 'news item' or 'story' or more generic 'article'.
I would even like to make a third distinction: the structure (custom fields) -- the form (type of content) -- and the content (relate).
An example of what a template could be in the future:
It doesn't really matter whether the themes are stored in the database or the file system. They could even be created by a drag-and-drop script ;-), but then I'm not a coder, I wouldn't be able to code that...
I also think it's important to see that taxonomies and folders are two very different ways of sorting! One works like resonance, the other like boxes... Actually, working with taxonomy in it's simplest form (tagging) is quite new and I think Gmail is a major trend setter in that! Their way of 'labelling' is completely based on resonance. I love it, but filing is still a very valid way of organizing stuff! It just depends on the situation which one is more suited to find your way around!
Yay! I love it, let's make templates! And rename book and outlining to folder and filing!!!
a few comments to
a few comments to that...
Still not sold on the filing terminology though I think you are heading in the right direction with that line of thinking. I know we are trying to relate terms to the office world pre-computers (or at least thats what I think of with folders in a filing cabinet) but I'm just not sure filing has the right ring to it. Sold on folders, definitely with you there, and like the idea of filing just think maybe there's a better word for it that I'm not putting my finger on right now.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
His table he called chair, and his chair he named dog...
+1 for Michelles Comment. Hehe, name Aperture just hole...
I like this discussion, even if one gets to a point, where one word is just as good as the other. Two factors might help:
Is a term Drupal-specific and names an entity that is special to Drupal architecture? ("Node" is such a term to me): If yes, we can name it as we want it, because there is no common word for that.
Are there well-conceived words for what a term describes, and the Drupal one is unnessecarily abstract, and there is maybe even a lack of consistent use inside Drupal? If yes, think about renaming it (Taxonomy might be a candidate, since "Tag" or "Category" is used in other systems, and even in Drupal it is switched back and forth between the terms)
But most important: Make it consistent. It is confusing if there are different terms for the same things, especially for new users. It is like a band name - any name is fine ($1 for the silliest band name that did not keep them from being successful), as long as it is used in a consistent way.
Life is a process
Life is a journey, not a destination
Words should be obvious, not all site admins are geeks.
Totally agree with eigentor, as much as some people might dislike the term node its so Drupal specific in this matter it is hard to change or look for a reasonable alternative.
What is key to understand with labels such as Taxonomy is that although it might be all enclosing on what it means it doesn’t get recognized by al lot of people. Learning people new words should be far from any usability discussion of course (as btopro pointed out), things should be obvious and require as less thought possible. Therefore I think dman actually misses the point, in trying to lean towards rich and accurate meanings which will only force people to learn these new words since they are not obvious...... This doesn’t mean you have to dumb down labels or lose its usefull distinction. (thinking broad with labels is definitely recommendable)
Please be very careful when assessing ones vocabulary, since al lot of Drupal admins don’t actually have English as there native language and therefore have a far smaller vocabulary.
Understanding what words people use to describe the functionality we are trying to rename might be more interesting then trying to find out what names we would use to describe the functionality. Usability tests? We have to find the common words used by new users (since generally people tend to use the same basic words - so no worries about 20 different results). So lets try to put up some kind of organisation(lists - long list) for the words we are finding to describe the functionality such as taxonomy and throw those towards the new users to choose from, if we evaluate these results we can make a far better assessment of what would be good words then just guessing what is good and what is not and excluding the actual problem facer. Because it might turn out to be words, some (or all? :P) actually don’t even like or aspect.
When you look over the usability tests done already, you quite surprisingly see that the people actually read the descriptions (witch are long!), shouldn’t those be more the focus of improvement, especially when it comes to making the so called useful distinction between certain functionality. However not looking for THE definition of the label since it doesn’t exsist most of the time, and most importantly not in maximum of 2 sentences.
Eigentor, consistency should be easy. We simply have to make a documentation about the controlled vocabulary. so all the words that are supposed to be standard in Drupal with its preferred term and what kinds of words fall under them - variants (If this doesn’t exist already). However should consistency also be applied as in taking over terminology from other cms's? For example if in 95% of the other CMS's its called tagging, why would we call it diffrent?
**Michelle* Drupal terminology has loooong been a issue I am afraid.
// For example if in 95% of
// For example if in 95% of the other CMS's its called tagging, why would we call it diffrent?
We call tagging tagging. The description for taxonomy includes the words 'categorisation' and 'tags' - I made very, very sure to include those in the patch which changed it back from categories so that people looking for 'tags' would find it in the top level administration menu. If you create a new vocabulary, you get the option for tags as the first item in the form. So it's right there, it's just not used to describe the whole system.
I think what we really do need is a couple of example vocabularies in the default install profile - one tagging, one structured vocabulary. In usability testing taxonomy itself didn't present any problems - but the distinction between vocabulary and term wasn't so clear. I'll probably open an issue for that.
//Please be very careful when assessing ones vocabulary, since a lot of Drupal admins don’t actually have English as there native language and therefore have a far smaller vocabulary.
We have translations in a lot of different languages so imo should be focusing on making translation easier rather than using a very limited English vocabulary. It's a lot easier to translate words like 'aperture' and 'taxonomy' - which are likely to have 1-1 equivalents - than 'hole'm 'post', 'content' which are much more subject to interpretation and potential error.
I may be wading late into a
I may be wading late into a conversation just to repeat what has already been said but:
I'd like to +1 for 'node' and 'node type'.
Unless you get rid of the concept and terminology of 'node' altogether, any user of Drupal will have to learn what it is at some point anyway. Why introduce confusion for the sake of not having to describe the term? In fact, because most users will come with no preconceived notion of what a 'node' is, they will be more likely to look that up immediately and to believe what they are told. The same cannot be said of 'content', 'post' or almost any other word that 'makes sense' to a new user.
To further that, I like node type because once you figure out node, node type doesn't (imho) even need to be explained. Template already has a meaning in Drupal (as well as in many people's minds, especially if they've come from another CMS) and has a huge potential for confusion.
People will very quicky grasp the concept of a node if you explain what it is, and use it consistently. Any attempt to ease the transition by obfuscating the concept with words you think a new already knows seems like it just leads to confusion.
Ronan
Gorton Studios - http://gortonstudios.com
Perhaps...
Even my parents understand the word 'file' to pertain to an otherwise nebulous piece of content of arbitrary type. I realize that those of us who are geeks might have trouble with it when using it to refer to data that is stored in a database rather than a filesystem, but it's a very well-known and well understood concept that I don't think 'node' nearly approaches in ease of comprehension. Go ahead - ask anybody on the street. What would you call a piece of content on a computer of non-specific type? And my guess is 99% would tell you it's a file.
I've had some troubles getting used to 'node' myself. Node - then it's a tree structure, right? Should have leaf nodes and a trunk - but these are no place to be found so it comes across as an unnatural perversion of the term. I'm not saying it's horrible, but these are the thoughts I have when I encounter it.
When we started applying the concepts of arbitrary storage to databases, we tended to call them 'blobs'. Even that is a win on 'node' IMAO, but I don't think it's a winner because it's also used to indicate something fat and ugly.
No, not really
"File" is indeed a nebulous piece of content of arbitrary type, but it's a piece of content of arbitrary type that one can view and manage in the file manager, or save on your desktop. People do not think of web content as files - nobody will tell you "there, look at this HTML file!" unless it's a physical file on your disk. Instead, they'll say "there, look at this HTML page!". "File" is actually worse than "node" because it's misleading instead of plain unknown to the user.
My personal opinion is that we should rename the "page" content type to "static page", and that "page" itself would make for a nice replacement for "node". But as I don't have any remotely scientific backup for that, it remains an opinion instead of a request.
So I asked...
So I asked a couple of students here what they thought and nobody had any issues with the concept of a 'node', but felt that using the term in URLs made the site look rather geeky. So I asked what would be a better replacement for the URLs and there seemed to be general consensus around using the term 'item', which wouldn't involve explaining to anybody what a node was and seems to adequately portray what they might expect to find by visiting that URL.
I might set this up in pathauto on the community board and solicit some more feedback.
Glossary and CCK glosssary
I am going to add a couple of links into this discussion:
CCK glossary: http://drupal.org/node/62532
Glossary module: http://drupal.org/project/glossary
Cheers,
Kieran
Drupal community adventure guide, Acquia Inc.
Drupal events, Drupal.org redesign