At the Hungarian community, we are organizing yearly local Drupal conferences ever since 2006 under the "Drupal Conference" and "Drupal Weekend" names. We've also just had our 22nd monthly meetup in a row. We've hosted Drupalcon Szeged 2008. Over these years, we've found that naming for all these events is tricky, and nowadays, the "Drupalcamp" name is sticky for local Drupal conferences. However István Palócz of the Hungarian community had a different dream around camps.
This year, we're gonna have the first Drupal Summer Camp in Hungary (and by the looks of Google search results maybe the first Drupal Summer Camp ever). Unfortunately (at least for my non-Hungarian speaking audience), the event is all in Hungarian (except all the jargon thrown around that is :).
The camp is on from the 23th of June to the 26th and is organized with community participation in mind. People can get experience translating interfaces and sharing their translations, look into drupal.org project maintainership aspects, work with the issue queues to get problems solved, etc. By the nature of being together for four consecutive days (with a complete dormitory floor rented for cost-concious and/or community addicted attendees), lots of hands-on experience can be gathered.
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!
Website admin skins/themes clearly have a big market. Just see many different options for Drupal hosted on drupal.org or some nice commercial ones on themeforest.net (not Drupal specific). Administration themes are great when you'd like to separate your administration interface from your front-end. And several Drupal studies showed that many people need this separation to understand where content is managed and what does everybody else see of the site. Of course your mileage may vary and there are all kinds of sites where community participation is on a level that admin/front end separation is meaningless. The point of this blog post is not even administration themes, so let's shelve that discussion.
Websites often replace traditional web applications as well, when the "front end" of the website is already some kind of data input / management UI, where the data is usually not in the form of textual posts with comments tagged by topics. Navigation is not primarily search based because pages for different functionality in the site are not searchable in a traditional sense. Finally, menus are not built by the site builders but rather the application author, putting in menus and navigational elements via code suited for the application.
In Drupal, this kind of theming needs a different approach compared to traditional admin themes, because the web application will most probably not offer the usual Drupal admin functions. For this role, a theme more like the general ones of themeforest's admin looks fits more.
With Drupalcon San Francisco just a few days away, being another great event including two days of "pure coding" and a ChX coder lounge each day for those who are inclined to join, I figured it would be a good idea to share some tips if you are about to work on Drupal 6 issues. Given the close to 2700 attendees coming, I don't know how many to expect on the code sprint days right before and after the conference, but I guess there will be people with diverse backgrounds as usual.
