Symphony.

Hey folks,

As you know, for Symphony 2.1 we’ve been working on some small-scale UI improvements… little things that will hopefully make the system easier to use and easier to understand. One area we’ve been looking at is the system’s terminology. We think there’s room for simplification and clarification on this front, and we wanted to ask all of you for help thinking things through.

We’ve already made a few changes in our experimental build, ones we thought were fairly obvious:

• renaming Pages to Views.
• renaming Authors to Users.
• removing the Components page and replacing it with dedicated index pages for Events, Data Sources, and Utilities.

What we’re trying to figure out now is if there are additional changes that could be made that would improve Symphony’s user experience. We don’t want to make changes just for change’s sake, but we’re open to replacing terms if:

1. the replacement is more accurate (as with Views and Users)
2. it makes the UI simpler
3. it reduces ambiguity, and
4. it gets rid of Symphony-specific terms in favor of more general ones

Bear in mind, we’re not interested in trading one kind of ambiguity for another, or overloading the system with buzzwords or jargon. Any suggestion will really need to be an unquestionable improvement for developers and end-users alike. With that in mind, we’re happy to hear your thoughts.

Also, with Components gone, the Blueprints menu now contains five items: Data Sources, Events, Sections, Utilties, and Views. We’re open to suggestions on whether that could be organized differently.

Thanks all. We look forward to your brilliant ideas :)

Following up the general post with some specific things that have been batted around.

Sections has been a candidate for replacement as it’s sort of a Symphony-specific term and not super-descriptive. “Content Types” and “Models” have been suggested, among other things, but so far nothing that’s been unanimously agreed upon.

As far as suggestions for reorganizing the Blueprints menu, we’ve considered:

• Model (Sections would be renamed to Models)
• View (Views and Utilities)
• Controller (DSes and Events)

and:

• Content Setup (Sections, DSes, ?Events)
• Front End (Views, Utilities, ?Events)

But there are problems with both of these…

Sections has been a candidate for replacement as it’s sort of a Symphony-specific term and not super-descriptive

To a developer’s mind, Model would be the obvious candidate. However if I were to tell a non-technical project manager, or client, that they should put content into the “Blog post model” then their eyes surely glaze over. Section makes sense to me since a layman would say “What section of the site is that content in?”. Some alternatives:

• Content
• Silo
• Table (they contain Fields after all!)

Because XSLT can become quite complex, and it is where a fair amount of view logic often sits, the separation of MVC isn’t strictly true. Symphony isn’t entirely MVC after all, so I don’t think we should attempt to name it as such. For example I might have a Page which contains an XSLT choose/when statement which decides which sub-template to load depending on certain conditions. In MVC-speak this is actually Controller logic, yet in Symphony this goes in a Page. When Pages are renamed Views, then you break the cleanliness of strict MVC by adding controller logic into views.

So while I think the move to Views makes some sense, I’m not sure a full rename to MVC would be appropriate.

From the Concepts list, other terms that have never made complete sense to me:

• Page Type — covers specific output types such as HTTP status codes and MIME types, as well as internal tagging, which is confusing
• Utilities — while most XSLT Utilites posted onto this site are re-usable functions, the Spectrum workspace uses a Utility for each “section” of the site. To me this is more appropriately named “Includes”

Should the Blueprints menu be ordered alphabetically, the order in which you create the items, or the order in which they feature in the page-lifecycle diagram we have?

I actually like the term Sections and think that it’s good that it’s Symphony specific. After all, Sections are a pretty big selling point of Symphony, considering your free to add anything to them to suit your site structure (instead of say WP’s Pages or Posts).

It might be a bit radical, but what about removing Utilities altogether? How often do developers edit these through the Symphony backend? I’ve never done so, it hasn’t been practical with the lack of tabbing, and really, a text editor is much more suited to it. Perhaps instead of removing it completely, it could be an extension and beefed up a little so that it has tabbing support and syntax highlighting.

I agree with Nick regarding Page Type, but can’t think of a suitable alternative. Flags or Modes?

Personally, I don’t see reason for renaming stuff. Only gets things more complicated to follow - like, in tutorials. :p

I wouldn’t vote for renaming sections or pages either. I think that these names are the best fit. Regarding components, well, splitting them up won’t make life easier.

I am not sure about the utilities, though. But I do think it’s good to keep ‘em separated from page templates.

If there is one thing we should really think about, isn’t it Blueprints?

@Nick:

Should the Blueprints menu be ordered alphabetically, the order in which you create the items, or the order in which they feature in the page-lifecycle diagram we have?

Alphabetically? Nope. Switching system languages might change the order! And: I always liked “working from bottom to top”.

I vote for “Views” as the first thing that confused me when switching to Symphony was that Pages were no “static pages” but more like “templates”.

Also, I vote for splitting up Events, DS and Utilities. Not because of the menu but because it will enable us to put each one in its own table row with additional info like Section, number of parameters, dependencies and whatnot. :-)

On the other hand, I don’t think that “utilities” should be renamed to “includes” as the “Downloads > XSLT Includes” section would get a weird name. :-)

And because I had to use the term “section” in the sentence before, I vote for renaming those too. :-) Basically all backend- and frontend-terms should not be homonymous.

So yeah, basically “Views” and “Content Tables”.

OK, next try:

A website is made up of several web pages. Basically a web server delivers a page if he receives a certain request.

So why the hell should Symphony deliver “views” to the outer world? I vote for pages.

Regarding sections, I agree with Nick: Talking to clients, it’s rather easy to explain content sections of a website. But I don’t see how I could explain content tables or even models.

A website is made up of several web pages. Basically a web server delivers a page if he receives a certain request.

So why the hell should Symphony deliver “views” to the outer world? I vote for pages.

For every distinct parameter, the visitor sees a different Page but they’re all basically a copy of the same View.

But I don’t see how I could explain content tables or even models.

“I can easily customize the Content Tables you’re seing in the backend”.

It’s all a matter of taste I guess.

Is it just me who feels alienated by “Blueprints”?

I don’t mind Blueprints, it links to construction to me, like the planning of a site. It makes sense to me because the items under the Blueprints menu are all ‘structure’ based, so no content is ever entered in there.

Although I cannot give specifics, I have noticed that the term “Blueprint” has been used more frequently in similar models to Symphony.

For me, view is more accurate term as a Symphony view is a superset of pages — it can house a series of web pages. Also, whilst this really shouldn’t be a major factor, I am quite tired of saying, “go to the pages page in Symphony”.

There are two predominant reasons why we have to split out the component page:

1. This eliminates a rogue page design in Symphony.
2. As phoque mentioned, this allows us to provide a dedicated areas for each component that allows for possible additional meta data, sorting and pagination.

@brendan: funny you should propose that utilities to be removed from Symphony — I also proposed that, although we didn’t come to a consensus. Although, when I approach a new Symphony build when I don’t have FTP access, it’s always nice to be able to check and debug through the admin. That being said, perhaps this should be a function for the file manager extension rather than a core feature. Utilities are nothing more than a XSLT files and it’s the only thing in the admin that the system don’t actually need to care about.

As for renaming the term Sections, I can go either way with this. I’m happy enough with keeping the term but I’m also not averse to the term “model”. I’m not keen on the term Content or Table. Content to me is the data held inside a structure, but does not communicate the structure that surrounds the content. Table is a generic term that has ambiguous meanings. For example, “blog content table”. Table in this case could mean the table view in the admin, the database table or the content table section. Whilst they do overlap in meaning, they denote different areas in a system.

If Sections is to be renamed, how about Structures?

Models and Views sounds good for me, and I think we shouldn’t remove the Utilities from menu.

While Nick makes some good points regarding the XSLT having controller logic, I’m with Allen: I’d like Views over Pages. I’ve come to refer to symphony pages as ‘Pages’ since you are often have to refer to an actual page (ie an html document served by Symphony) while explaining Pages (Symphony’s view logic mechanism.

I think the utilties in-browser editing could maybe be abstracted to a general xslt editor that could browse your workspace (and only edit xslt of course), and remove ‘utilties’ from the Symphony nomenclature.

@ashooner Also it would be nice using Bespin as an in-browse editor..

I’m also in favor of Views over Pages and separating out the Components menu.

Also, despite some missteps in version 1, I think ExpressionEngine 2 has done pretty well with their terminology, though might not be all that applicable for Symphony. Worth a look:

http://expressionengine.com/public_beta/docs/cp/index.html

While Nick makes some good points regarding the XSLT having controller logic, I’m with Allen: I’d like Views over Pages

Me too: Views makes sense to me, since it’s more developer speak. I think my comment was more along the lines of “Views is good, but stop with the MVC similarities there”. Symphony isn’t MVC therefore naming it thusly is a misconception, and may draw disappointment for those investing time in trying it out expecting it to be as such.

The discussion around Utilities really depends on how you choose to use them. I’ve seen developers store almost all XSLT in pages, and only keep Utilities downloaded from this site in their utilities folder (date formatting, pagination etc). Conversely, I’ve seen developers neatly abstract page-building XSLT into well-named Utilities, leaving their page XSLT very lean indeed. Both are correct, and both make use of the “utilities” concept. But they are both using the concept in very different ways.

Zend MVC (oh dear, MVC again!) makes a distinction between:

• Routing (the URLs used to access views)
• Views
• Helpers (globally-accessible functions and logic)

Symphony rolls routing and views together (which is a good thing), so I wonder whether “XSLT Utilities” would better be named “XSLT Helpers”.

When I first came to Symphony/XSLT I thought there was a physical difference between the page XSLT files and Utilities. They are, of course, both just XSL templates. One is tied to a page/view, and another is “floating” that can be included wherever appropriate.

The term Templates from ExpressionEngine would be misleading in the context of Symphony given when we say templates we are referring to <xsl:template> elements within an XSLT stylesheet.

Perhaps Utilities should be renamed Stylesheets? However to a web-development crowd, the term Stylesheets immediately has a connotation of CSS, and not XSLT’s <xsl:stylesheet>…

Symphony rolls routing and views together (which is a good thing), so I wonder whether “XSLT Utilities” would better be named “XSLT Helpers”.

Hmm, not sure about that. For example, the master.xsl isn’t a helper but a template for all my pages. What about XSL Templates?