Revised: May 2, 2010
If you are just coming in to read about this, we've gone through quite a few versions and the below text no longer represents the latest collective vision. Please view the highest revision file and read through the comments to get an idea of the current status of this.
I'm kinda jumping in here, but here goes nothing! I'm a designer/programmer/themer who put together some workflow ideas for Views in Omnigraffle. I believe people are used to guided setup conventions, whether they use them or not - it's found on many interfaces including wireless routers, and software such as Dreamweaver when setting up a new site. The edit page could be structured very much like a new node creation page, as we can assume that a node might be created first and they are already comfortable with this type of process. The different steps would be housed inside of the vertical tab switcher, allowing the user to click back at any point while editing the view to change or view relevant settings. The groupings I chose were based on a rough MVC separation where one would first set up the data linkage (model), configure sorting and filters (controller), and lastly the output display (view). I took a piece of the UI from the new d7 dashboard and put the view displays up top. This is a radical change from what is there now and I'm sure some might not like it, but I was just playing around with some ideas.
Naming view and choosing 'View Type'
This would be the first tab - I think the 'View Description' field should be listed first in the form, as people generally tend to expect the 'title' as being the first thing they fill out when making new content. The 'View name' (which is really only for the system to use) would be listed second, less prominent, and auto-filled with a suggested name based on the description. I personally think this should happen system-wide in the case of unique internal names. I'm willing to bet a great many people get the error message and have to go back and change the unique name after reading al the fine print. Perhaps it could be set up much like the url alias on a node creation page, where a box can be checked to make one automagically. I would really love to hear your feedback on this!
The same tab would contain the 'View type' selector. I didn't change this part much, but it could still use some more attention.
After this step in the way Views is currently setup, the next page could be overwhelming with nearly every option available on screen at once. This is great from the standpoint of those familiar with Views, but for a beginner it's not optimal.
Tab 1: View settings
Simply a grouping of some of the different settings. Paging removed from here and grouped with the other output display elements.
Tab 2: Data
It seemed logical to try and put the 'row style' or as I called it 'data retrieval' here with relationships, but there are some things that need to be ironed out as far as separating the fields from any visual style elements. For now I just put the configure button in here and also in the display style in a later tab. This would would also house other types of data sources as Views expands to include more in the future. This could use a better name as well, perhaps 'Data sources' ?
Tab 3: Arguments
Tab 4: Filters and sorting
This is almost structured so far like an actual sql query - most things past this point are dealing with how things are shown on screen. I've also thought about the idea of having some things already put in by default, such as a filter for node:published, and ordering by post date. Users would have a filter for if they are active... again, just tossing ideas out there.
Tab 5: Output Display
I tried very hard to think about how to group things, and this seems very logical to me - header up top, content in middle, empty text, and footer below. The pager settings are also in here, as they are tied to the display of the content. This area encompasses the 'view' from the MVC idea.
So that's it - the bottom part would act the same, and you can see how it looks partially on the 'Output display' tab. Views is amazing, and personally I could work with how it looks just fine - but I really wanted to come at this from the standpoint of ultimate usability and a great user experience for view creation and editing. Brining in some new d7 conventions are important, as I think there should be consistency across the entire admin interface.
To me, this was a great exercise in learning more about UX, and I am not expecting anything from this. I believe it's important to open our minds to new workflows, and reach beyond what is there already.