Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Archive /

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, biapar, Willr, Ingo, simon_w

The role of CMS


Reply


5 Posts   2534 Views

Avatar
Sigurd

Forum Moderator, 628 Posts

19 July 2007 at 5:55pm

One of the things I feel we've done really well (and I make mention of this to people when they are learning about the CMS, and most are excited by it) is what we put in, and leave out, of the CMS.

In general, its targetted at a comms/marketing person with average IT skills, who can then manage their website. Its not over simplified into a blogging tool that prevents understanding/manipulating the tree, nor is it cluttered with confusing tools or terminology that only developers use. This puts is in a niche, I feel.

So... with the advent of the modules, we're getting into areas where API Keys and Galleries with resizing metods are being asked. In the past this would be entered as PHP config.

I just wanted to raise the idea that by default, what you see in the CMS is the product of a webdeveloper, for a website owner to manage. Any API Keys, Gallery Resizing methods, et al, which I see as more for a developer than site owner, may exist in the CMS, but only in a way that does not clutter or confuse. This may mean putting things into another tab, providing sensible defaults, et al.

Avatar
Sam

Administrator, 685 Posts

19 July 2007 at 10:26pm

One of the important design philosophies is having a clear separation between the interfaces for authors, designers, and developers.

Historically, PHP has been the developer's interface, SS has been the designer's interface, and the CMS has been the author's interface.

However, I think that there is probably room for a "designer/developer level access" in the CMS that is different from the author's interface.

Some things that this access could open up:

* Configuration settings such as API keys
* Locked pages that regular authors can't delete (for example, you don't want authors to go deleting the checkout page on an e-commerce site, or the home page).

But, until we have such an interface, I think it's better to keep these settings in _config.php.

We need to remember that the purpose of the CMS is to let people manage a site that has already been set up - creating and maintaining content and other site settings. It is *NOT* supposed to be where you "build a site", except within very limited domains, such as setting up a site with out-of-the-box features. That's what separates us from Joomla.

Avatar
Jedateach

Forum Moderator, 232 Posts

20 July 2007 at 12:22pm

That page locking would be handy for the blog module.

I've mentioned proposed page types here:
http://trac.silverstripe.com/silverstripe/wiki/BlogModule

Avatar
Sean

Forum Moderator, 922 Posts

24 July 2007 at 11:03pm

Edited: 24/07/2007 11:08pm

Can't agree more Sam and Sig, SilverStripe is where it is because of this clear separation, I think it's in a great position - plus it allows anyone who isn't familiar with php/html/css to become familiar with it. :-)

Avatar
msantang

Community Member, 41 Posts

25 July 2007 at 12:05am

I agree, one of the strongest points of SS is that separation and simplicity for the user.

I made proyects for some clients with joomla that is very popular and feature rich but no user frendly at all.

You pay the features with usability.

I hope that SS can coul still be simple and clear for the user. But powerfull and feature rich for the developers.