[Draft] MODx 0.9.7+ Terminology Proposal

Thanks Grad for clarifying your thoughts, a lot of interresting ideas in there !
I mean, it’s great to initiate and feed this kind of debate

For the record, I am not against Content Fields and against unifying terminology, I had some reserve about changing TVs name IF (and only if) they were still tied to templates (I was not clear about this in fact).

But as usual with terminology, we can all have different takes on naming (latest debate was Ditto’s parameters). While I can be a bit passionate about it, I know it’s just the tip of the iceberg. "Bleeding edge" technical choices, the richness of the team, the vitality of the community is what matters. Terminology is a communication tool, and as long as it’s coherent and understandable it’s fine by me. I’ll drop my 2 cents but I’ll sure learn from other 2 cents as I did here...

I think Jason sums it up perfectly when he reminds us that the vision behind this all is "to provide a content management framework that enables an infinite number of roles to more easily participate in the lifecycle of the project" (great last post by the way, bookmarked !).

I guess the debate here illustrates the adjusting process of the diversity of profiles (and cultures) in the team, and it’s a good sign that we’re passionnate about it

I certainly agree with Jason’s vision, "without the technical details, the project IMO, becomes only attractive to end-users" : from day one I clicked with this, because making MODx better for end users requires to attract contributors and we sure managed well in this regard when I look at the guys (and gals) among us today (group hug time )

Anyway, great debate !
This is so dense I’ll take some time to process it before I can even really feed the debate further...

Quote from: davidm at Mar 19, 2007, 06:24 PM

For the record, I am not against Content Fields and against unifying terminology, I had some reserve about changing TVs name IF (and only if) they were still tied to templates (I was not clear about this in fact).

On this topic, I’m convinced "Content Elements" (originally just Elements) is the way to go for layman’s terms. "Elements of content on your web page" is all some site stakeholders ever need to know. How that content element is implemented in the background should not even be part of the discussion with a non-technical user; this is designer and/or developer territory: deciding what kind of source content is processed in what way with what parameters to produce what kind of output. Answering the questions "what kind of element should I use here and how should I present it for editing" are the real challenges, and I think that’s where documentation can really help adopters who want to become more intimately acquainted with the technology

Also note for 0.9.7, Content Elements (and Tags) encompasses all the current functionality and behavior of MODx Templates, Template Vars, Chunks, Snippets, Plugins, Modules, Link tags, System Setting tags, and Placeholders, includes only a few new ones, but adds the potential for an infinite variety of others to be developed easily as core extensions (i.e. no hacking required). Only 1.0 will feature the ability to tie any Content Element to any Web Resource directly. So what you are referring to as Content Fields would simply be any combination of the new 1.0 Resource Elements concept (or Web Resource Content Elements if you want to be formal), Content Elements defined as children of a modTemplate Content Element (formerly TV’s), and any other Content Elements simply included in page content somewhere.

Quote from: OpenGeek at Mar 19, 2007, 05:44 PM

This is why I have provided laymen’s terms along with technical classes and descriptions associated with the terms. (...) designers will have a slightly better understanding, and developers will rely on the technical information to guide them to the fulfillment of end-user concepts. But without the technical details, the project IMO, becomes only attractive to end-users.

I fully agree we should provide both laymen’s lingo and technical description at the same time. However, for those 3 target groups (end-user, designer, developer) I would use only 2 sets.

IMO laymen’s lingo should be used to describe the front- and back-end interface as this is what end-users and designer will work with. A designer will want to talk to you, the developer, using lingo describing the interface (templates, fields, links etc.), having in mind the end-user, who will be using them. And the designer should be able to understand easily what the developer will provide as the interface elements. Thus we should use one set of terms describing, what users and designers interact with. That’s what I wanted to point out, as my impression was David wanted to use two sets of terms for those interface elements.

On the other hand, the developer needs to have technical documentation describing the framework architecture, APIs, interaction of elements, parser routine etc., which have nothing to do with end-user/designer laymen’s lingo.

Quote from: OpenGeek at Mar 19, 2007, 07:05 PM

(...) "Elements of content on your web page" is all some site stakeholders ever need to know. How that content element is implemented in the background should not even be part of the discussion with a non-technical user;

My point exactly, only better said

Quote from: OpenGeek

this is designer and/or developer territory: deciding what kind of source content is processed in what way with what parameters to produce what kind of output.

I guess the "what kind", "what way" and "what kind" again is key here. Of course the client decides which content he wants displayed here and there, he also gives the green light for the layout and design etc... but in a way the system is a black box that the client doesn’t need (and most of the time want) to understand *how*.

I admit I sometimes try to translate things into layman terms when they ask how it works (or where they ask something which is not included in contract and is more complex to set up). It helps setting boundaries to their imagination (I’d call that the "magic box" effect : I often am confronted to the "it’s a web app, therefore it’s easy (and cheap)" assumption...). What the client needs is answers to his particular concerns, often it will be : how much does the software cost ? how user permissions are handled / how safe is the system ? how hard is it to learn to use it to publish and manage content / how much training is required ? how often are upgrades and how complex and risky is it ? Will it work on my web server or do I need to upgrade it ? etc... most of it will adress management and money issues if you’re talking with the CEO, might be more technical with a more specialized interlocutor (but that’s for bigger companies, personnally I deal with SMEs).

Quote from: OpenGeek

Answering the questions "what kind of element should I use here and how should I present it for editing" are the real challenges, and I think that’s where documentation can really help adopters who want to become more intimately acquainted with the technology

It sure is, and with the transition from 0.9.7 to 1.0 it will be even truer to attract coders and devs
I guess it will be critical to attract to us lots of them from 0.9.7 and on, so that they have time to get acquainted with the technology as you say.

Perspective : look at who has come to MODx - first geeks from all backgrounds, then designers and power users, now more and more coders, and maybe at some point end users (I remember talk of MODx distros) ?

Quote from: OpenGeek

Also note for 0.9.7, Content Elements (and Tags) encompasses all the current functionality and behavior of MODx Templates, Template Vars, Chunks, (...) So what you are referring to as Content Fields would simply be any combination of the new 1.0 Resource Elements concept (or Web Resource Content Elements if you want to be formal), Content Elements defined as children of a modTemplate Content Element (formerly TV’s), and any other Content Elements simply included in page content somewhere.

Chrystal clear now, thanks for that summary

Quote from: grad at Mar 20, 2007, 03:13 AM

I fully agree we should provide both laymen’s lingo and technical description at the same time. However, for those 3 target groups (end-user, designer, developer) I would use only 2 sets. (...) Thus we should use one set of terms describing, what users and designers interact with. That’s what I wanted to point out, as my impression was David wanted to use two sets of terms for those interface elements. On the other hand, the developer needs to have technical documentation describing the framework architecture, APIs, interaction of elements, parser routine etc., which have nothing to do with end-user/designer laymen’s lingo.

Now I didn’t want to use 3 sets of terms : one for dev, one for designer, one for end-user. Originally (before reading what Jason had in mind and in store), I just needed 2 sets of terms (but that’s also because we currently have non-layman terms like TVs or @bindings). Also, remember that some of us work "alone" as freelance and most of the time we do design and insert logic into templates but quite little or no code writing (thanks to the powerful extension at hand such as Ditto).

If it can be done, one set of terms could act as a powerful communication tool between various profile : dev, coder, designer, CEO, management, end user and that’s exactly what Jason refers too when he uses "stakeholders" (very management lingo of you Jason ). Given the way things are evolving and what Jason explained, I think we’ll get there and that will give us another edge to capitalize on for sales and marketing