This one would likely take a lot of overhaul the page composer…but I think it could be very helpful in accelerating the learning curve for new admins/builders. In my experience Skuid admins tend to struggle the most with the concept of a model when they first start learning to build with Skuid. On the other hand, the concept of the Component is very intuitive. So re-designing the page composer to be oriented around the Component would be valuable for new admins/builders.
For example…
When a user places a Component on a page, the first tab within the Component’s properties section could be named “Data” and it would allow the user to setup the Model properties (naming it “Data” to fully abstract away the concept of Models).
If Skuid auto-named each model as Pat suggested here, that Model’s data could still be referenced in other actions, conditions, etc. but it would be named something like “Field from another Component’s Data”…instead of “Field from another model”.
Regarding Model Fields, I usually add those to the model through the component’s “Add Fields” action, and find that having the ability to add fields to a model through both ways (directly to the model, and through component actions) tends to be a bit redundant/confusing for admins.
Regarding Model Conditions, “Always On” conditions could be setup under the Data tab. For filterable conditions I usually add those through the component’s “Add Features –> Filters” action. For “Always Off” conditions…well I don’t know why these exist…just delete the condition if it’s always going to be off.
Regarding Model Actions, these could more intuitively be built through action sequences on the relevant Component features (buttons, filters, fields, etc.)
IMHO…I also think JS and CSS resources should be relegated as navigational links next to “View/Edit XML”. That way all of those advanced developer tools are out of the way, forcing admins/builders to focus first on using the declarative tools (i.e. action sequences and theming options). Too often I see developers resort first to those developer resources…because they’re developers, and developers always want to write code before trying a declarative solution. Ultimately, they might start questioning the value proposition of Skuid if they are always developing pages using JS, CSS, HTML within templates instead of using the declarative tools. But as we know, the value proposition of Skuid is to enable non-developers (like me 
to build beautiful, intuitive software solutions without writing code.
So in this way, I think it would be easier for non-developers to quickly grasp the value of Skuid if the Page Composer experience were oriented around the only 2 Skuid features needed to build a page: 1) Components 2) Action Sequences
And it’s all those non-developers that will see the most value in your product, and then be willing to purchase it…
Conlan, we’re actually talking about many of the things you’ve brought up. Some of them are big lifts in terms of development effort. Though, as far as aligning with how we’re thinking about things and trying to simplify and streamline a user’s experience, you’re right on the money. Good stuff. Thanks for sharing.
