Simpleviews on Drupal 7 - how we did it

Early on in the development of Drupal Gardens, it was clear that we needed some type of simple Views-like functionality. You know, letting users set up simple lists of content beyond what is included with Drupal 7 core, but simpler than the Views UI which can be quite intimidating to first-time users. Drupal Gardens' goals include making Drupal easy to use, and that sometimes comes with feature sacrifices. You cannot do everything you could do with a self-hosted solution, but you can do most things easier. If you exceed what Drupal Gardens can do, no worries, simply export your code and database and adopt any Drupal 7 module.

So when looking at our options for implementation, we had the obvious choice to roll our own code and live with that or postpone this feature to get released with Views D7. There is some very nice discussion going on around the Views D7 UI at http://groups.drupal.org/node/64143 and it is evident it is not a small task. For Gardens, we needed a very easy to use UI with a limited feature set. And of course there is a module for that, its called Simpleviews, from Jeff Eaton himself.

We decided to contribute to the community efforts within our limited scope, so we took Simpleviews and upgraded it to Drupal 7 and posted it for review in the issue queue. But Simpleviews depends on Views, right? So without a Drupal 7 version of Views, how useful could that all be? Whether by chance or Jeff Eaton's genius, Simpleviews is actually a pretty standalone module. It only requires Views where it clears the Views cache. The architecture of Views lends itself very well to these kinds of alternative interfaces because it works with array dumps, so an alternate UI module can just have its own ways to generate these arrays.

The original Simpleviews UI screenshot from the module's page

Simpleviews itself stores all simpleview settings in a database table and generates Views arrays out of that. So if we don't have Views, we can just look at the settings in the database and generate output based on that. This way we get the best of Simpleviews by being forward compatible with Views if we later decide to include Views in its entirety, while we can have a very simple and lightweight module to generate output for the small use-cases we cover today. Because Simpleviews is indeed very simple, the backend for generating pages based on the settings there is also surprisingly simple.

My initial version of this backend module was 167 lines with plenty of code comments, which covered all kinds of funky Simpleviews features, except exposed filters. Honestly, we attempt to practice restraint around adding more features to it, but currently it already grown to 460 lines to support some additional things like taxonomy term based filtering and style support for blocks. It is still a little-bitty module compared to Views.

What are we going to do with this feature in the future? Well, we are still not decided yet. We certainly want to provide a lot more Views-like functionality and features this year, but we are starting with design and UX first -- and then we will decide what back-end supports it best. We might use all or some of Views in the future, we might tone down its UI, we might use another alternate UI, we might keep using an alternate backend. It is an ongoing discussion at the Gardens team at this stage. I believe that there is no point in publishing our current backend module on drupal.org given its interim nature, but that does not make it closed source or unreleased. Any Gardens site that is exported will include a copy of this module, and it is released under the GPL.

What do you think about our approach? How would you make the Views user-experience so easy anyone could use it without getting help? If your suggestion pertains to the Views module itself, please contribute to the existing groups discussion, otherwise leave a comment. Thank you!