Thanks @steffenschmidt for clarifying. I’m going to jump straight to the end of your comment as this is an interesting point to discuss:
I sit on the other side of this argument. I think the designers, developers and technical expertise in a project should be predefining and controlling how the website owners and editors use the system. I guess this is a slightly controversial view - it goes against the grain compared to many other CMS’ - but my preference is for the end users to have a very simple UI that allows them to do everything they need to do as easily as possible, and nothing more.
This doesn’t mean PushType can’t be a flexible and powerful CMS that is suitable for complex real world web projects. I agree that the CMS should be as flexible as it can. I just question where the flexibility should sit and who should be responsible for wielding that power. I think that the most flexible (and efficient) way of creating complex content models and relationships is through a programming interface, not a user interface.
There’s another important factor to this argument as well. One of the driving motivations behind PushType is to create a product that is easy for beginners to learn how to use Ruby to build websites. I want people to be experimenting and tinkering with the structure of their site by getting their hands dirty with code.
I mention these things because they’re kind of fundamental to PushType’s identity. Managing the underlying structure and behaviour of the site with code, and a very simple UI is what PushType is all about. That identity and vision helps shape all features and design decisions.
Apologies for getting a bit philosophical on you there.
Most of the simplified components you describe above are already achievable with the existing built in field types (especially the
StructureField). As @danobot mentions, with creative use of node classes you can probably give end users quite a degree of flexibility. Some kind of component (or whatever we call it) system will come eventually and will probably go some way towards what you’re suggesting, but I wouldn’t favour a major deviation from our current identity so I doubt we’ll go as far as a drag and drop “page builder” type solution.