integrate form builder to allow content creation view modes.

Great features, I will hope we can create a new content is very simple like as http://backpackit.com.

Since this is more of a site builder task than a content author task, this is not something the Spark team plans to tackle, at least for the first while. Lowering in importance. Keep these kinds of suggestions coming, though! It never hurts to catalog existing solutions.

This looks to me like a case-study for the problems with persona-based development. The "site-builder"/"content author" separation is great in theory, but in my experience clients end up unhappily stuck with things they can't change on their own, forced to pay extra for stuff they can go to a third-party provider like Wufoo and do it themselves. This leaves them feeling (rightly or wrongly) very much like they did when they had to hire somebody to recode their static pages.

The reality of web maintenance is that content authors need to build landing pages, and if we don't want them to ruin our work we have to give them tools to do it decently.

Yes, it's totally true that the line between site builder and content author is really blurry, and at times might not even exist, depending on the site. From my perspective, it helps to think of things in terms of tasks, and how often those tasks are performed, and by whom on a given site.

For example, installing and configuring modules. I don't think there'd be any argument about the fact that the Drupal modules page completely sucks. It's way over-loaded with useless information (and missing other key information), it's impossible without a great deal of Ctrl+F to find what you're looking for, the interface to add new modules is absolutely horrid and unusable, etc. However. It's a page that is visited very infrequently once the site is originally set up (and this is normally done with someone more techie or at least with a tolerance for tinkering), and it's not something that the sucker who's in front of Drupal every day actually putting stuff on the site is encountered with more than once in awhile (if ever). Therefore, redesigning the modules page won't be a priority of Spark, even though everyone would be happy to build a statue to whoever solves this problem. :)

Contrast this with something like creating content, which might be done several dozens of times per day by hundreds of people on a busy site. Getting that process streamlined and usable is absolutely critical to people genuinely enjoying using Drupal. And that's true regardless if you're a content editor, a site builder, or an end user of a site; the entire point of a CMS/CMF is to manage C. :D And while forms are one type of C, what we plan to focus on, at least at first, are more general solutions that are broadly applicable to lots of different types of C, since this has a much bigger overall impact on the UX.

Hope that makes sense.

fixed some wording issues

Core didn't end up doing this, so neither did we.