Descriptive Terminology = "Semantic Intuitiveness"? (was: MODScripts?)

Quote from: Carsten at Aug 10, 2005, 11:45 AM

err, ok!

Need to split this thread!  I’m going to have a hell of time trying to remember all of the important details and which "term" to comment on.

Why? It’s all focused 100% on what to call things?

@ module -- sounds like from the description that "3rd party plugin" might work.  a module is a plugin but from a 3rd party.

Not exactly. The SMF module is a bridget between SMF and MODx. Not SMF itself. So third party is not a requirement. We can have native MODx modules. I lean towards what Adam said: no real diff b/n plugins/modules/pacakges. Or packages are just a collection thereof an handled by the to be done installer.

@ chunk -- I still don’t get it.  The above has helped a bit but ... still missing the basic understanding.

They’re placeholders that might just reference other placeholders. The referenced placeholders might also just be interpretted, but the chunk itself is not. If it weren’t for the very useful "real" placeholders, I’d say that thats what we call them.

Update: I missed one, see above.

Ok,

How about we change the name from Chunks to Containers? Why? Because they are used to store text, html, snippet tags, etc

That’s not a bad idea, but it seems that it could easily be confused with Packages which are containers for snippets, chunks, plugins, etc. But I like the line of thougth though, there has to be a better word [Adam says while scratching his head and thinking to himself]

Quote from: aNoble at Aug 10, 2005, 02:48 PM

That’s not a bad idea, but it seems that it could easily be confused with Packages which are containers for snippets, chunks, plugins, etc. But I like the line of thougth though, there has to be a better word [Adam says while scratching his head and thinking to himself] 

Well then we just need to call Packages Installers. Some along the MODx Visual Installer line.

I prefer to call them Installers. For example:

SMF Installer
FCK RichText Installer
PhotoGallery Installer
etc, etc

That sounds really good to me. Installer makes perfect sense.

I think that coming up with good icons for each of these will be just as important as names. Sometimes a picture is worth a thousand words. I think we should go with combinations of icons like XP does. We could have a standard icons for page, code, widget, user, etc. and combine them together so that people get the idea of what something is without having to analyze the name.

That’s one thing that I think Microsoft did right. You know what most XP icons are just becaus you’re familiar with the standard icons and can put two and two together. If you see an icon that is a combination of a folder and a globe, you know it’s an internet folder.

Let me clarify that I don’t think that we should use the actual XP icons. I think that’s way too overdone. I just like the way they combine different elements together.

Yeah I agree with you 100% Adam icons are very important as well as names.

Anyone else for Containers and Installers?

Here’s a draft of how we might think of describing things after much deliberation:

Beginner Concepts:

Control Panel or Manager  (currently Manager)
The heart of configuring MODx, your site, and creating your initial content.

Content  (currently Documents)
What end users interact with in MODx, typically a web page. This can also be a CSS file, a javascript include, downloadable document, etc.

Templates
The MODx centerpiece which most Content uses. We still need to define a simple and direct way for people to quickly create different types of content, like a shopping cart products page, a blog, etc. Do we need sub-templates, or content templates, or content settings?

[*Content Fields*]  (currently TVs & [*content*])
You can have as few or as many content fields associated with a page in MODx as you’d like. They can be simple text fields, WYSIWYG text editors for complex data entry, pop-up lists, radio button options, etc. [*Content*] is automatically defined for every page that is created in MODx.

Intermediate Concepts:

[[Capsules]]  (currently Snippets & Chunks)
Capsules are holders for little pieces of code and static HTML which you may wish to use on multiple pages. You can set a flag to "exectuable" to denote the Capsule contains logic or code that should be evaulated (like a custom PHP script). (merge snippets and chunks which have almost identical table structures anyway)

Display Controls  Widgets  (formerly Display & Input Controls)
Display Controls affect the way Content Fields appear on the Edit Content page (i.e., when creating new web pages) in the Control Panel. They can also affect the way content is displayed on front-end web pages. Examples for input Display Controls include select lists, Rich Text Editors and radio buttons, for instance. Output Display Controls include dyanmic animation efffects, Rich Text Editor form controls, data grids and more.

Advanced Concepts:

[+Placeholders+]  [+Proxies+]  (currently Placeholders)
Are programattically defined placeholders that represent other pieces off content. These are useful for instance when creating forms.

Plugins
Act on system events to alter the default behavior of the system. This could include adding WYSIWYG editoors, or even changing the way Capsules are parsesd.

Installers  (currently Packages & Modules)
Pre-packaged collections of Capsules, Content Fileds, Database Queries, and/or external PHP code that is used to bring additional functionality to or link with MODx. Examples include Forum bridging code to synchronize users, Image galleries, and more.

I think this looks really good. Nothing jumps out at me as too techie or too vague. I’m not especially fond of Proxies though, I think I liked Placeholder better.

Once we get this finalized I think we should add a Glossary page to the documentaiton. One place where you can look up meanings to terms like these.

I’m 50/50 on Proxy. It’s a lot shorter than Placeholder, though, and does at least to me connote a more on-the-fly concept. However, Placeholder is reported to me by more than one as much more intuitive. So we probably can revert that.

Widgets, however, are another thing:

widgets
are fast becoming a certain thing
wonder if that would confuse...

Think Dashboard Widgets (OS X) or Konfabulator ...

A chunk of css/java/xhmtl code
running on a desktop platform

Modules are often frequently reported as confusing, even too really smart and competent developers. Any thoughts there along the lines of the above?