Yeah I get what you're shooting for.. We typically use page types for that.

so for your example, I would make a page type for products. I would then define anything I wanted to grab outside of the collection as a page attribute. I'd define stuff like the 5 pictures as block areas, either 5 specific ones if i had a really layout centric design, or just a "images" area of the design was more flexible...

client would then be able to add a new page type labeled "product" and they could even get defaults from page defaults you setup in the dashboard.

make sense?

I see what you are saying. I think I was thinking more in terms of streamlining the addition of a type of data that would appear multiple times on one page. Does that makes sense?

I have some doubts that you could use the same block for a lot of projects. You often have to add or remove a few fields..

I was never able to streamline such things. Even a team table looks different for every project. Block are there to be re-used but if you have to modify it all the time you basically can't use it twice and therefore page attributes are more appropriate from my point of view.

If it's just about data field, you need an hours to understand how to build a "data block".

I don't see it as any different than the custom CMS types of applications we used to develop - customer asks for a utility to add a particular type of data to a site, you build an admin for them to do that.

I agree that a data block would take care of the problem, I'm thinking a little more conceptually with this post about a possible feature in the future that would speed development of sites.

yeah that's why i'm not that into it.

i think you solve problems that way for your clients because other apps have taught you that's the only way to solve the technology problem...
1) define EXACTLY what the page will have and do.
2) write some use cases and build a custom back end for it.
3) hand off to client and hope they like it and their needs don't change.

what works so great about c5 is you can be a bit more flexible than that...
1) define the purpose of the page, who is it communicating with, what data is it likely to have in the get go, what's might happen later?
2) define a page type and give it a theme that makes it look good but gives areas room to grow...
3) hand off a unique page type that lets them add the data you've defined in the project in the right area, but also lets them try out new ideas... maybe they want to post a press release to the bottom of that product page.. maybe their product just won an award and they want to add that image to the product page...

if you define everything in such absolute terms from the get-go and put it into one fixed block with an admin interface on the back end, you've basically cut the legs out of the in-context editing experience for your end client..

it's a different way of thinking, but i know once you get there you and your clients will love it.

Oh, trust me, I am totally on board. However, in my experience, only some clients fit into the category you are aiming for (nothing wrong with aiming high!). There will be, for the next few years anyway, still be the contingent that want you to hold their hand, guide them through the process, and make it as brainless as possible.

Anyway, just throwing out ideas.

I have yet to meet a client who prefers going to a separate back end interface where the enter some values in a form that looks nothing like the page they're shooting for over the in-context editing.

I think if you just put some good data in the page defaults so when they make a new page of "product" type its not empty, you'll be amazed at how quickly your clients "get it". What I typically hear is "ahhh, this always seemed like the way it should be but i'm so used to having to goto a complicated back end that I brought a tape recorder to this meeting so i wouldn't forget how to do stuff!"

Where we have broken out of that model in the past is specific elements in the page.. So we've built "link blocks" that basically work like an auto-nav but backwards - you have to pick which pages to link to and it handles formatting for them. Could they just have done that with the content block, sure, but giving them a bit more hand holding in a custom block makes sense to me there..

I just get really weary when you're making a block that is a combination of existing data elements into a conceptual group specific to a client.. by all means, solve problems however makes sense to you, but this is exactly why there are both page types and themes.. page types work well for this

I'm sorry if I've misrepresented what I was thinking.

I'm in no way wanting to go back to the bad old days of a separate back end interface.

My original thought at the beginning of this thread was that it would be nice to have a 'block maker' that would automate creation of blocks that defined a specific kind of information. There are lots of blocks already that define a specific kind of information (the Image block, for example).

I understand these can be created just by making new blocks and uploading them to the /blocks directory. However, looking forward with this project, wouldn't it be nice if creation of blocks (at least simple ones that just allow the insertion of a specific collection of information, like the Image block), could be given an interface in the dashboard. You see what I am getting at? Clients love the front end interface!

but i really feel like this is what the in-context editing > page type > block area architecture already does.

asking a client to go into the backend, find a "block configurator" add some fields of varying types... then add this new block to the page.. all while you hope that actually works, provides enough flexibility without destroying legacy content...
its just a lot of geeky stuff for a marketing type to figure out..

build it the way i'm suggesting, and the client will just add a form block for that survey they're thinking about on their own - right from the page when they had the idea... you'll get a call asking if you can add some validation and improve formatting.. they get creative, you get nicely thought out work requests.. no one has to learn anything new...

I think this may be one of those spots where our "unique" approach to the problem means it's gonna take a few real world implementations before the benefits to our solution become clear and intuitive.

Play more with page types, page attributes (very important and under used) and default content.

Ok, we're now we're closer to the right track! Again, I apologize for being unclear..

I had imagined the "Block Creator" would be for the benefit of the developer, not the client, to facilitate rapid developing (or at the very least rapid prototyping). Maybe I'm just being lazy... :D

On a side note, thanks everyone for taking so much time to talk about this, even if we got way off track in the middle, and it's just a conceptual thought. Our office is loving C5 development (we're on our second site with the software now), and at the very least I have learned that people respond quickly on the forums. You guys are great, and the software is awesome.

keep on trucking! thx
-frz