I've spent a lot of my 'between' time thinking about what I want to see for the next major revisions of Views, and I've finally decided to sit down and actually create a road map. Views 3 isn't like Views 2 in the sense that there will be a rewrite. On the contrary, I'm really happy with the foundation of Views 2 and I believe that we have a solid system for building on. What I'm unhappy with are features that got left out, or that I didn't even know we would need. The enhanced flexibility of Views 2 opened the door for a wide array of features and the best part is that Views is now so widely used that I'm not the only person doing work on this. In fact, Views 3 has the potential to be primarily community work rather than just me doin' my thing. This is quite a transition for me, as I'm used to being the developer, plugging away and working on my own schedule.

Here is the short list of things that I want for Views 3. This is not exhaustive, but these are the major points. Many of them are already being worked on. However, there's over a hundred patches in the Views queue that I need to review, and I'm not including a whole lot of those in this list. But I know that many of them are worthy and will get in, possibly in both the 2 and 3 branches.

Make as much functionality pluggable as possible

Query backend pluggable

Right now Views only knows how to do SQL. But several very dedicated contributors have worked to move aside the query object so that it can be a plugin. What does this mean? Integration directly with Solr, FlickrAPI. Heck, any Restful API can be used. In theory this could mean integration with RDF (though my personal feelings on RDF are not in keeping with the greater sentiment these days). I've actually committed this to the 3.x branch already. http://drupal.org/node/293841

Header/footer/empty text pluggable

Right now the header and footer just go through ordinary filters. Sure you can put PHP there, but one thing I've learned is that if you're using Views as part of your module and you want to distribute it, having PHP embedded in the view is bad. In fact, embedding PHP anywhere has turned out to not be a great long term solution. Therefore these desperately need to be pluggable so that we can do more things with the header and footer area. Especially if they can get some knowledge of the arguments so we can do more things there.

Translation plugin

Nedjo Rogers started work on a plugin to help i18n better integrate with Views a few months ago. This work seems to have been picked up again and there is a patch here: http://drupal.org/node/357529. Anyone interested in properly integrating Views with i18n should participate, because I think this is important and it's an area where I don't 100% understand all of the parameters. From what I can tell, the patch is actually very close, and it just needs some people to really work on it.

Views result caching

Jeff Eaton took some code I wrote for Panels and wrote what appears to be a fantastic caching plugin for Views: http://drupal.org/node/468824. It can cache either the results of the query or the output of the view and the mechanism for figuring out when the cache needs to be expired is completely pluggable. This one will probably get checked into the 2.x branch because it's that good.

Pager pluggable

When I was nearly done with Views and I was playing with the AJAX stuff, I wanted a smaller pager to put into blocks, because the standard pager doesn't fit. And having AJAX in a block is really handy, so I added the mini pager. I should have simply made it a plugin, but not just on the output side, on the input side too. So that we can do more stuff with pagers. See my blog post on how we can fix the pager system. That can be applied to Views. Sure, it may not necessarily match the built in pager system, but if a site is mostly Views powered, then it may not matter too much, and the power and flexibility it provides could be really nice.

Better support for view as form

I would like to see Views be able to do mass editing, bulk operations, etc as plugins rather than as styles, to be able to more fully integrate the form right into the view. Right now this is possible through styles but is not as clean as I would like it to be. It would require fields to become form aware, and forms to be able to know what to do with fields. It's an interesting project.

Exposed form updates

Exposed forms need a lot of love. They required a lot of hacking to get to work right, and there are still many problems with them, and many, many feature requests. I want to see a lot of them go in, finally.

Own section in UI

To start with, the exposed forms have enough possible settings that they need their own section in the UI so that we can give them their settings. We can intelligently unset this if nothing is using the exposed form or maybe we can require it to be turned on before the 'expose' button shows up on anything.

Exposed sorts

Filters are not the only thing that should be exposed. Sorts. Work is under way on this: http://drupal.org/node/228510

Control of text on 'button'

Paired with a proper translation plugin, this would be a nice little touch.

Exposed form styles?

I don't know for sure if this makes sense, but in theory this could go a long way toward helping control how an exposed form looks. Right now it's hard pushed into one look and that's not always what people want.

Form builder integration

Maybe this would be in place of form styles, but integrating it with quicksketch's form builder in order to have greater control over the exposed form would be nice.

Ability to have view not run when no value selected

People constantly ask for this feature, wherein the view will be empty until something has been selected in the exposed filters.

Retool to rely on CTools

CTools was built in part from work I did on Views. It's time to throw away old code and move to relying on CTools. This would make Views itself slightly smaller, and put CTools out there for everyone to use. CTools would effectively become a Drupal API extension, and I think that's a good thing.

Forms

All of Views' form.inc file can be removed and rely pretty much direclty on CTools version instead.

AJAX

CTools AJAX tools are actually superior to Views' versions. Views would need to be cleaned up a little but a lot of the .js code in Views could be stripped down and made a lot better by using the CTools AJAX tools.

Tabs

The one thing CTools didn't get from Views is the tabs. Those are using a wrapper around jquery UI. Of course, there is now a jquery UI module, so we need to figure out if the tabs should go into CTools or if we should require JQuery UI module.

Other features

This is a list of everything else. Not that these are less important, just that there aren't many individual pieces to them.

Group by support

There are the views calc and views groupby modules. We can make them more or less obsolete by putting proper group by support directly into Views, supporting aggregate functions for all or at least most fields, and fixing all of the handlers to understand how to deal with GROUP BY queries. Issue: http://drupal.org/node/396380

OR support

This requires two things. One, there needs to be a way to group filters (and the exposed sorts could use this same functionality) together in the UI. Once this is done, we then need to go through all of the existing arguments and filters and make the WHERE GROUP aware. There are some filters in Views that are known to fail with the views_or module. These can be fixed and need to be.

Better visibility of arguments for access plugins

It turns out to be very difficult to write access plugins that deny access based upon an argument. This is a lot easier with a context system. Well, if we rely on CTools, we can leverage context for this.

Argument validator reverse transform for summary links

The argument validator has features that allow it to transform arguments. For example, it can take an taxonomy name or synonym and translate it into a term ID. But what it can't do is translate that *back* to the proper argument when using the summary view. This just requires an expansion to validation, and some smarts in the summary view.

Attach feed to arbitrary URL

Right now feeds can only attach to other displays on the same view. But a comment RSS feed would really like to be able to attach to a node with the right argument. This needs to be able to watch URLs and attach Views to them. It needs to do this in a way that doesn't kill performance, however, so needs a good design to do it right.

Revision logging

It would be nice to be able to log when Views are changed. Because Views properties are all declared, we should be able to expand on this and record not only who made changes but record exactly what was changed.

Re-order displays in UI

This could probably go into 2.x, really. We just need to leverage tablesorts and allow displays to be re-ordered. Their order does matter for some things and the fact that you cannot re-order them is a bit of a pain.