(Anyone who wants to add anything, please do. I've spent very little time with Views, I looked at it for assessment purposes, because it keeps getting mentioned, in one way or another.)

What is the Views module?

In one sentence, Views constructs custom lists from database tables.

There are some twists of usuability, the most striking to me was that it leverages the Drupal URL wildcard scheme, so that the list can reflect user navigation. It can also show it's own filters, and so allow on-page user modification.

Differences between Views and a 'Menu' module

A Views list is a menu. But it is a menu with one dimension. The Drupal 'navigation' menu is two dimensional. A menu such as the 'navigation' menu can be regarded as a set of lists organised through a tree structure. 

(Views)


item#1
item#2
item#3
...

(2D Menu)

item#1
item#2
item#3 --+-----item#1
...             |        item#2
                |        item#3
                |         ....
                |
                + -----------------item#1
                                         item#2
                                         item#3
                                         ...

Let's extend Views! That would be a killer module!

I'm sure people have groped towards, or jumped for, this idea. But I can see objections.

Views has had a truckload of talent thrown at it. Code spurts, Summer of Code, I'm not up with it, but you should know how much time and talent that interface must have taken. Now you suggest they put a tree handler on top of it?

Views is one heck of a module. I needed to extend my PHP allocation to 500M to get it running reliably. Drupal does care about the small user too, there is one of it's strengths. Also, take a look at the Views issue queue. They must have 500 issues at any one point, mostly about the user displays and subsequent interaction.

The above practicalities are not a decisive argument. When you propose for access to contrib ('I want to make a module'), one condition is that your work does not offer simple, lightweight versions of existing work. The next argument might be decisive, though...

Gluing software together is a matter of magic. When someone put a web form on top of a computer communication protocol, you get webpages then email - fabulous. When a Windows disc burner decides it is going to become 'a multimedia experience' you get a shapeless, resource chewing mess. I'm none too convinced that putting a tree over Views would work as well as you might hope.

Let's talk about the menu itself, not the lists it may page. A 2D menu can only really handle, with the technology we have (page space, HTML), as much information as will fit in a simple link. So all Views manipulation of content goes unused. Unwanted, as who would want an ultra slow menu that you have to scroll down, however much info each link contains? Users would start to loose track of the treelike structure, which is the key here. That argument holds, to a lesser extent, for all the other aspects of Views. We don't need/want as many fields, filters (well, maybe we do want the filters), relationships...

If Views was 1/5 the module it is, this might be an idea. But would you want Views to be 1/5 of what it is?

You stomp on dreams, pal.

The video group I'm part of use Vegas and VirtualDub. I know a dream.

What does this mean for menu modules?

Unless the Views or the core teams have a wizard new project in mind, all the little menu modules will continue to live, grow, thrive and die.

What might Taxonomy Treemenu learn from Views?

See this post by jpTaranto. JP was curious that Treemenu was not using stock system paths, so a user can't use Views lists or Pathauto type features. But therein is our clue.

If building on top of Views is not practical (or even desirable?) you can still work alongside the module. Treemenu uses a fast, consistent, paging solution by dependancy on Taxonomy Router. But it's only a programming step away to provide a Views template that mimics the Taxonomy Router routing. We might even be able to bend the dependencies so that a user can pick between Taxonomy Router (simple, Drupalish, fully templated if you know what you want your site to look like) and Views (the power).

The other thing I get from Views is that we can learn from it. Have you noticed how many Treemenu posts say 'can I select/filter' this or that? What they all seem to be poking at is this - can Treemenu work like Views? Please?

This is quite a step. Have you ever seen anything like that? A 2D menu with filters, sorting, and all the rest of it? Yet, I think, possible. The 4.1 BETA of Treemenu has some limited node ordering. In effect, an admin user can turn parts of the menu upside down. Which is cool, useful, and probably the future of this module.

Further thoughts, please post...