Proposal 1 is the ideal as it proposes a “spreadshet like” data structuring experience.
However, I don’t agree with the fact that “AWMs should be created from any page”.
The fact that competitors are mixing and matching data types - plain text with structured, one structure with another structure, that structures are so seamless is, indeed, “cool” at demo level but:
- it can easily get very rich / bloated / complex / hairy. The whole mixing is easy to handle when you’re the one creating it (therefore the bias of the demo / test), but when you need to consume some that has been created by someone else, the seamlessness removes explicit and it can hinder understanding of the data, impact clarity. Or maybe I am just too old. However, some of our users have my age (or more).
- honestly, I’m not that sure that this is done so often (outside of a demo / test usecase) that it’s really worth the cost of doing this and the complexity of the resulting UI.
Proposal 1 obviously doesn’t have the same cost as proposal 2.
Now, about proposal number 2, I’m not sure I understand what are the specific changes from your proposal in terms of ease of use / UX (besides the design things). You’ll need to explain them to me, probably, and describe how each of them impacts the usability and why. Or maybe just describe the problems that you see in the current wizard, screen by screen?
Also, your images for the wizard are missing access to the configuration of a field, which is actually very important for some fields (the date format is configured in there, the fact that a user picker is single select or multiselect, etc.)
Thanks,
Anca