17488 Posts in 4473 Topics by 1978 members
|Go to End|
Core Development Team
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.
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.
20 July 2007 at 12:22pm
That page locking would be handy for the blog module.
I've mentioned proposed page types here:
24 July 2007 at 11:03pm Last edited: 24 July 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.
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.
|Go to Top|