Design proposal for /admin/build/views/add or /structure/views/add

I like what I see here, and I'm all for simplifying the views interface, but I think item #3 above must be stressed.. Simplification at the loss of functionality would not be an acceptable outcome.

Fear not, I will enforce #3; loss of features is something I am very much against.

As the maintainer of views slideshow these comments are somewhat slanted towards how I would work with it.

1) I'm assuming somewhere else there is a more advanced interface and this is the "simple" interface.
2) I would like to expose options for the display for the simple interface. In my case it would be something like Transitions (fade, slide right, pinch, etc.) How would this be displayed on the form?

Generally I like the look. I think the hardest part will be finding good defaults. Thanks for getting this started.

What we see so far is only the 'create a new view' interface. It is analogous to the first page when you create a new view right now. It does not address what happens when you click continue.

@#4 Since it's including unformatted in display styles isn't it doing a little more than that? Or are you saying we should ignore that part for this post?

Yes the design is doing more than just the 1st page of current views - but it is a wizard - and of course wizard's only present the 70-80% use case - and the remaining 20-30% happens after you press 'continue'

@#6 got it. Didn't really realize this was a wizard. I was thinking you would save this and the view would be created. Should have paid attention to the Save & Continue button.

Really interesting idea.
Providing the most commonly used options while getting the full UI after "continue" seems like the best of both worlds.

It also gives us a place to do some really common things. For node views we could generally default to using the published filter, which people want. We could avoid the UI annoyance you get right now where you create a view which assumes fields, but there are no fields, so you get validation errors until you add one. Little stuff like that can probably be handled with the wizardy thing.

One other thing: A goal we discussed with merlin is to define an API so views add-in developers can define what "80% use cases" they expose via the wizard. e.g. they could add just enough to the list of Display formats, or sort options, for the 80% use case.

What if there were 3 buttons at the end of the "new view" form: "Save," "Save and configure," and "Cancel"? The "Save" button would just set up the view as configured on the "new view" form without even showing you the advanced settings, giving the 70-80% of people a lower barrier to entry. The "Save and configure" button would take you to the normal advanced settings page for the other 20-30% of people who want to go more in-depth.

#11 makes a good point. Some users will only ever want this simple screen. They may want to "Save" and never see the advanced screen. Moreover, when they edit their view in the future they will want to return to this simple interface again rather than going to the advanced one.

So maybe the buttons could be "Save", "Configure Advanced Settings", and "Cancel". Clicking "Save" will save the simple view and that's it. Clicking "Configure Advanced Settings" will take you to the advanced views interface where you can customize the powerful stuff (views attachments, relationships, etc). But if you return to edit a view that has no advanced settings, then you return to this simpler wizard-like interface. If you did "Configure Advanced Settings" then there is no going back and from then on editing that view is always in the advanced interface.

+1 for this entire UX design idea

I disagree with the idea of separating the two interfaces as entirely as is suggested in #12. There are essentially two workflows here: "create" and "configure." Users don't have to configure, but they do have to create. When you're done creating, you have the option of configuring, but you can never go back to the create form for something that has already been created.

Discussing with Earl in IRC - we need some thought as to how the initial select box is organized. If there are 40 node types, the mock-ups no longer make sense because, for example, I'll have to scroll an inconveniently long way to get to Users.

If you're expecting a select list with 40 options, that's probably an indication that the paradigm is wrong. Probably the choice is not between "blog posts," "article posts," and "users," but instead between "blog and article posts but not images," "image posts," and "users." So the idea of choosing a single content type for a view may not be the right one anyway.

In other words, I would say start with just the basic tables (node, user, taxonomy) in the "Show" select box, and dynamically show the most basic filters based on the table chosen. (For example I would say creating a view for certain taxonomy terms is a relatively rare use case since most people would just create one view with a taxonomy term argument; but node types definitely makes sense there as a common filter worth dynamically exposing.)

I also like the form element type I call "autocomplete select," where it's a multi-select box or a radio list plus a textfield, and the select/radio options get filtered down as you type in the textfield. However most of the time when you need to use something like that, there may be other ways to look at to reduce the number of options you have first.

Interesting commentary.

One of the basic use cases is a regular, newish site builder that says "I want to make a list of my blog posts." It's one of the most common cases, and we do want to make that one as easy as possible.

Because of the way types work, ecommerce sites (for example) can have an ungodly number of types because subtle differences between products have different data needs. I've personally worked on a site with over 60 content types. Those are outside the norm, but they do happen.

Some possibilities I can think of:

1) Include a setting on the node type page (defaults to on if not previously set) that controls whether or not this particular content type appears in the list. Total control by smart admins, basic case for others.
2) We have a smart algorithm. Do we have 10 or fewer content types? Include them all. Do we have 10 or more Look for an algorithm that might try to figure out which are the 'most important' content types. That might just be to create a list of really common content types. Pick up all of those until we reach some magic number, fill that out with others we don't know about in whatever order they show up. Try to watch similar names. Since sites with lots of content types might have most of them as product_* we might be able to detect this.
3) Ignore it and let the list get very large.

For 1), I'm assuming that mostly only expert-level sites will care about their types being excluded, and those expert level sites will have an easier time setting that flag when they create the content type than having to set it somewhere else.

When I said e-commerce I meant sites that use it, not the module itself. It depends entirely upon the people building the site. If they add a bunch of different product node types that have subtly different data.

It would be interesting to get some data on the bell curve of how many sites use a given number of content types. If over 95% of sites have under 20 content types, then ignoring the problem sounds reasonable.

However, I still believe that if there is a possibility that a significant number of users will have a bad experience, then the approach is probably wrong. For example in the currently suggested model, on a site with 60 content types it will be difficult to create a user view. There's no reason that the number of content types should affect how hard it is to create a user view.

I think there is a lot of potential in option 2 from #18, but I would do it a bit differently. If there are <10 node types, the currently suggested model works fine. If there are >= 10 node types, then have the first select box be just for the table, and dynamically display the node type filter if the node table is chosen. Because it's one thing if you have 60 node types in a select list that says it's for node types, and it's another if you have 60 node types plus some other stuff in a select list of indistinct purpose. Also I think that would be much less confusing than having some node types appear but not others -- it avoids the moment of "uh-oh, where did my node types go?"

By the way, node types aren't the only thing for which this could be a potential problem. User roles could be another one. It may make sense to have a view of Administrator users, a view of Authenticated users, a view of Content Creators, or whatever. But a lot of sites have lots of user roles and it doesn't make sense to show them all in a large select list along with node types, terms from certain vocabularies, etc. In other words there needs to be some distinct criteria to say "this filter is really that important that it can create a bunch more options in the top-level select list."

The new Ui has been committed to 7.x-3.x.
Mission accomplished.