Thread

I freely admit, I am being deliberately provocative, but my underlying motives are not driven by malice or mischief. Philosophically, I’m increasingly inclined to think that there is no such thing as a Content Management System; there are simply ways of managing some kinds of content. The proposal that I put before the house is that EE is not ‘A’ content management system; it is actually little more than a fancy text management system. ( I acknowledge that EE has primitive image management capabilities (I also very readily admit that I’ve had absolutely no personal experience of using any of them and in that regard I may well be talking out of my bottom), but I reafirm my central contention that the prime emphasis of EE is simply predicated on the management of words; as far as EE is concerned, for example, tabular data is some bizarre, exotic species of content that no-one should have to deal with and remain sane.)

Surely, a content management system, ‘manages’ content. Regardless, in these, post-web-2.x days, of what that content might be. Content for the web, as I understand it in my eveyday working life, is a mix of, for example; interactive Flash technologies, tabular data (remember that stuff?), video, sound, images, dynamically generated numeric/textual information, and good-old-fashioned static stuff. And, more usually, a heady mix of them all.

The reason for the post is that I’m reading a lot lately about the demise of old-fashioned stalwart web authoring tools such as Dreamweaver and their perceived failings in dealing with a contemporaneous world of shifting, plastic ‘content’, compared to more ‘appropriate’ management tools, such as Drupal Joomla, WP and, of course, EE.

The nub, of course, is that such proclamists either deliberately or inadvertantly fail to distinguish between the tools of design, authoriship, proof of concept modelling, etc., and the subsequent tools of maintenance of a post-realised actualite.

I very much like the idea that EE is much a more sophisticated mechanism of output management than, say, WP. It’s certainly easier to turn a bespoke design into something EE can understand than it is in say, WP, but nevertheless, the stark reality appears to be that EE, like its competitors, is still a tool of rarified limitations. EE’s very central construct and taxonomic argot is focussed around the manipulation of words, indeed, on one of the web’s most infectious of neologisms the - welog - is the metaphorical Lego building block upon which all EE sites are founded. A manager of words it may be - par excellence, even - but a true content management system it aint.
The question is; what needs to be done to make it true content management system?

I freely admit, I am being deliberately provocative, but my underlying motives are not driven by malice or mischief. Philosophically, I’m increasingly inclined to think that there is no such thing as a Content Management System; there are simply ways of managing some kinds of content.

That’s probably the philosophy of the minority, and certainly a semantic distinction. First, define a CMS.

From Wikipedia:

A content management system (CMS) is a computer application used to create, edit, manage, search and publish various kinds of digital media and electronic text.[1] CMSs are frequently used for storing, controlling, versioning, and publishing industry-specific documentation such as news articles, operators’ manuals, technical manuals, sales guides, and marketing brochures. The content managed may include computer files, image media, audio files, video files, electronic documents, and Web content. These concepts represent integrated and interdependent layers.

Looks to me as though EE falls smack into the middle of the definition of a CMS. Therefore, if it walks like a duck, talks like a duck, it’s a duck.

The proposal that I put before the house is that EE is not ‘A’ content management system; it is actually little more than a fancy text management system.

Plausible, except for all the capability that EE provides that goes beyond mere text. Images, graphics, audio, video, PHP, Javascript, blah, blah, blah—all are components of digital media and electronic text relative to web sites.

(I also very readily admit that I’ve had absolutely no personal experience of using any of them and in that regard I may well be talking out of my bottom)

Ideas and concepts have to be formed somewhere.

the prime emphasis of EE is simply predicated on the management of words; as far as EE is concerned, for example, tabular data is some bizarre, exotic species of content that no-one should have to deal with and remain sane.

That’s a definition that is paying lip service to the capabilities of EE as a CMS and not wholly in context. You’re not wrong with something like “EE mostly manages words” because most web sites are made of words. But that’s not all that EE does, and not all that you find in web sites in 2009.

Surely, a content management system, ‘manages’ content.

OK, and the problem is…?

Content for the web, as I understand it in my eveyday working life, is a mix of, for example; interactive Flash technologies, tabular data (remember that stuff?), video, sound, images, dynamically generated numeric/textual information, and good-old-fashioned static stuff. And, more usually, a heady mix of them all.

All of which may or may not be included in most web sites, some far more so than others. Regardless, if it’s content that gets managed by an application, it’s fair to call the application a CMS, even if all that is managed is the text which appears, as content, on the web site. It may not be a very capable CMS, or somewhat thin on features and capabilities, but a CMS none the less.

I’m reading a lot lately about the demise of old-fashioned stalwart web authoring tools such as Dreamweaver and their perceived failings in dealing with a contemporaneous world of shifting, plastic ‘content’, compared to more ‘appropriate’ management tools, such as Drupal Joomla, WP and, of course, EE.

Sigh. There are trends, and there are those that predict them, identify them, categorize them, assail them. Yet trends continue, unabated, as the precursor to change.

Obviously, Dreamweaver and friends have not, and are not likely, to simply disappear because of recent trends toward more dynamic content management systems. I’ve used Dreamweaver since version 1.0, and yet seldom use it these days because most sites I manage require a nominal amount of XHTML, plenty of CSS, and a growing multitude of “content components.” Whereas the web was once pretty much text with sprinkled graphics here and there, it’s far more complex these days.

The nub, of course, is that such proclamists either deliberately or inadvertantly fail to distinguish between the tools of design, authoriship, proof of concept modelling, etc., and the subsequent tools of maintenance of a post-realised actualite.

Here, Here!!

I very much like the idea that EE is much a more sophisticated mechanism of output management than, say, WP. It’s certainly easier to turn a bespoke design into something EE can understand than it is in say, WP, but nevertheless, the stark reality appears to be that EE, like its competitors, is still a tool of rarified limitations.

And there are contemporary CMS apps for the masses without limitations? Oh, do tell…

EE’s very central construct and taxonomic argot is focussed around the manipulation of words, indeed, on one of the web’s most infectious of neologisms the - welog - is the metaphorical Lego building block upon which all EE sites are founded. A manager of words it may be - par excellence, even - but a true content management system it aint.

That sounds oh so plausible, what with the enlightened 2.0 verbiage and all. But without effectively defining what a content management system is at the outset, and having it agree with a common understanding of same, and with an inability to match EE’s alleged shortcomings to same, the argument fails to become anything more than a passing fancy, or, a fancy that was passed, much as a mist in the night (or, after a visit to Taco Bell).

;-)

The question is; what needs to be done to make it true content management system?

Change your definition of a CMS to match what EE does.

Bravo, Ronnie, splendid riposte!

I especially liked your bit about ideas having to originate from somewhere, even though you somewhat mischievously quoted me out of context; it still raised a chuckle. I’m not entirely convinced that you could claim that PHP and Javascript can be catagorised as content. At least, not in the same sense as words, numbers and images. Languages, technologies - perhaps; content? Not so sure.

Surely, a content management system, ‘manages’ content.

OK, and the problem is…?

My post was not entirely driven by some introverted piece of navel gazing, but was triggered by a conversation I enjoyed with one of our clients whose static site consists overwhelmingly of a series of frequently updated tables. (I posted a thread about it some recent weeks back.) The bottom line is that try as I might, I couldn’t produce a practical or philosophical reason why he should switch from Contribute to do what he was doing with those tables (i.e., managing content) to EE. The Contribute route was dead simple, copy, paste, apply CSS style to resulting table, publish, Bingo!. Job done in seconds. Failing to convince him of the tables argument meant that he simply couldn’t see the benefits of moving to EE in the wider scheme of things. And in that case, if I’m honest, neither could I really.

It struck me that tables - or specifically, tabular data - are intrinsically and fundamentally, just content. Indeed, tables are one of the web’s oldest forms of content. It seems odd that a content management application like EE should make such a meal of such an ostensibly simple thing as tables. This is not a philosophical or semantic nicety, this is simply a task that our client, a non-specialist, needs to undertake many times a day. He wants a nice, simple solution to manage his content and who could blame him?

I especially liked your bit about ideas having to originate from somewhere, even though you somewhat mischievously quoted me out of context; it still raised a chuckle.

I’ve had my share of ideas that later proved to originate from the same part of my anatomy.

I’m not entirely convinced that you could claim that PHP and Javascript can be catagorised as content. At least, not in the same sense as words, numbers and images. Languages, technologies - perhaps; content? Not so sure.

Short term memory loss is a wonderful device for debaters, so I’m not sure that I meant PHP and Javascript in the context of “content” per se. One of the benefits of writing things down in a somewhat permanent record such as a forum, is that I can always come back later to see if I agree with what I wrote. Sometimes I do, sometimes I don’t. In this case, I think that what I may have meant was more akin to EE’s ability to use PHP and Javascript as tools to help manage content, instead of being the content.

The bottom line is that try as I might, I couldn’t produce a practical or philosophical reason why he should switch from Contribute to do what he was doing with those tables (i.e., managing content) to EE. The Contribute route was dead simple, copy, paste, apply CSS style to resulting table, publish, Bingo!. Job done in seconds. Failing to convince him of the tables argument meant that he simply couldn’t see the benefits of moving to EE in the wider scheme of things. And in that case, if I’m honest, neither could I really.

And that should be an acceptable conclusion. The old saying of, “If the only tool you know how to use is a hammer, then every problem looks like a nail” bears witness in your example.

If the tool works well, and automating a particular procedure brings with it more expense, more effort, more maintenance, then one must ask, “Why bother?”

It struck me that tables - or specifically, tabular data - are intrinsically and fundamentally, just content. Indeed, tables are one of the web’s oldest forms of content. It seems odd that a content management application like EE should make such a meal of such an ostensibly simple thing as tables.

That would be a better context for the issue—not whether EE is a CMS, but whether EE, as a self described and somewhat acknowledged CMS—comfortably or ably handles a common element of web page content—tabular data.

How EE handles tabular data depends on other items, of course. How the data is gathered, stored, formatted, sorted, etc. For some sites, EE may not handle tabular data so well. Then again, I have a feeling that many web sites these days don’t have much tabular data to be managed anyway.

This is not a philosophical or semantic nicety, this is simply a task that our client, a non-specialist, needs to undertake many times a day. He wants a nice, simple solution to manage his content and who could blame him?

Understood and agreed. I have had some clients who like what I do and how I do it and my pragmatic approach—then I show them EE and what it can do for them and give them a ball park figure to encompass my experience, talent, and ability to help them achieve their objectives. Then I ask them what they need to have done. Sometimes I end up setting them up with WordPress.

It struck me that tables - or specifically, tabular data - are intrinsically and fundamentally, just content. Indeed, tables are one of the web’s oldest forms of content. It seems odd that a content management application like EE should make such a meal of such an ostensibly simple thing as tables.

Obviously, I’m not dealing with a host of other issues and ideas you’ve brought up; but I would like to deal with Expression Engine in tabular data. EE can be used to make tabular data dead simple. How it does it is more about the developer, but there is a plugin/maybe extension that can handle simple tabular data; and for complex projects, I’ve just used the EE weblog engine. For example, for a National Data Project, I used EE so that the client could add new tables, new data, and modify data at will, without having to learn how to format or otherwise code the data. The project is in two phases, national data (overall), then broken out by state. One example of the national data is here:  NAHIC:// National Data Project: Suicide Attempts.

But all that was required was basic conceptualization to use Expression Engine to handle it. The client needed multiple table types (i.e gender tables, race tables, age tables, various combination tables); tables associated with objectives or classification (i.e. suicide attempts, drug and alcohol related deaths, sex, etc.); then the actual data.

The sample system generates and pulls tables based on objectives, directly from EE. So if the client gets age data as related to gender, for suicide attempt, they just create a new record in the Data Table/Publish area; set the related objective (suicide attempts) and the table type ( gender/age) then just add data to the fields. A new table with new data is auto-generated.

That said, since a lot of data was being entered in, I did have to get the client use to searching for rows of data for editing purposes versus scanning the Edit Tab. Since, the data is named in a standard manner: objective short name: table type: row or basically if you are looking for the males age 14-21 who’ve made suicide attempts, you’d be looking for: Suicide Attempts: Gender/Age: Male (14-21) as the title. It’s easier to do a title search on Objective: Table Type than it is to scan the couple hundred records, especially since the record count is growing as state data comes on board.

Additionally, using Andrew Weaver’s CSVGrab, and possible for the future Solspace’s Importer, it’s fairly easy to bring the data directly over from Excel Spreadsheets, FileMaker or even BBEdit. In fact, I frequently use FileMaker to clean there data, since the data entry people are not very consistent. They may use M or Male or API instead of Asian Pacific Islander, etc.

That’s just to say, these things can be done. EE is really very flexible and better yet extensible. I frequently find it’s my ability to imagine how something would work that is the limitation to what it can do. Though also sometimes the specificity of my imagination pushes me into limitations as well.

without going in to all the fancy language and talking around the point so you try not to offend…blah blah blah.

Tabular content? The whole system is saved into a Database… You can have as much or as little tabular content as you like. The problem you are identifying here is not Content, but work flow and process… Ignoring the obvious of your client needing or wishing to edit the content when they are away from a machine with Contribute installed…

There are a multitude of plugins that allow you to quickly and easily handle tabular data. Whether it be via manual updates into a page that looks like MS Excel, or whether you are quickly and easily importing a large DB/spreadsheet (table of content) from a csv file… In my eyes, uploading and importing a CSV is going to be quicker than any process in contribute.

Well, thank you allgood2 for the astonishingly detailed response. You’ve clearly got to grips with tables and EE, that much is obvious and it’s very kind of you to offer your methodology as an exemplar. One of the snags that our client faces is that the subject, nature and scope of the tables that are being handled are completely arbitrary; they originate from a wide variety of external sources though they all arrive as unformatted Excel documents. Among recent examples are trade figures for a large multinational which featured alongside EU immigration figures. The only thing that the tables may have in common is that once the CSS formatting is applied, then they all adopt the same corporate style. Beyond that there is very little common ground at all between them. It is this innate variability of the tables’ subject matter and scope that seems to stymie EE’s ability to streamline the process of getting the raw Excel files into a web page with the minimum of manual intervention.

To paraphrase Mr. Spock (I believe); It’s content, but not as we know it, Jim.

I guess, I’m missing the complication. If the data doesn’t need to be in Expression Engine databases (individually manipulated), basically your just saying you want either a method to read data from a file and format it to a page, or a way to place data in a post and apply formatting?  The first, would probably require PHP, since the file exists outside of EE; the second is just a matter of CSS, because though the data would exist in EE, it would be a single record, not multiple.

At the basics all tables are columns and rows. The variation is primarily in the data, but additionally in the column and row headers. My process just reduced the number of header types, but also allows me to add new ones on the fly. Though, the biggest component, for the client was the need to be able to manipulate data on the on-going bases: add new records, modify percentages, delete rows or entire tables, if necessary. If they hadn’t needed to access, modify, and otherwise manipulate data on the somewhat routine basis, then a basic BBEdit script to convert rows and columns to comma-separate or tab data to generate tables, and pasting that data into a single post would have probably been my offering to them.

I guess I feel, either the data needs to manipulatable (large scale) via EE or it doesn’t. If it doesn’t then pretty much like a paragraph of formatted text. Paste it in where it needs to go, give it an id and a class for formatting purposes and your done.

I’m surprised anyone is really replying to the original post more than once.

This is clearly a troll. No matter what you say it’s going to be met with another excuse or direction. If the OP can’t go any further than even understanding what a CMS is, and what it means, you’re going way over his head trying to explain anything in any sort of depth here.

I’m surprised anyone is really replying to the original post more than once.

This is clearly a troll. No matter what you say it’s going to be met with another excuse or direction. If the OP can’t go any further than even understanding what a CMS is, and what it means, you’re going way over his head trying to explain anything in any sort of depth here.

I agree with JT.

Nearly most of the ‘points’ made by the OP (original poster) are null & void.
A clear understanding of many of the functions of EE is vital, important and pertinent to the design, construction, implementation and maintenance of any ‘Powered By ExpressionEngine’ website.

Anyone who wants to better understand and use EE would have already come across the tutorials by http://eeinsider.com/ , or http://devot-ee.com/ , http://train-ee.com/
Anyone who doesn’t take it upon themselves to educate themselves, have so few posts, not as for help or advice - well, as JT says, they are clearly trolls.