So in case you’re not aware, I kind of injected myself - along with a group of other people - in to this project called Gnomepal. We connected, we started, we realized we didn’t know what we were doing - so now we’re going to do some serious thinking first. It’s the natural order of things. We’ve been talking about a road map. This could be the start of such a roadmap.
I was doing some work last night for Adam Kalsey on a Drupal 6 install. Adam is one of the earliest project members, along with Chris. I had some insights during that work which helped flesh out somewhat what I think we’re trying to do. I was setting up one portion of a community website: a wiki. And I had to install two modules, setup up different content types, and configure it all to work together. I knew what I had to do only because I’d done it before. I remember the first time it took me hours. And I’m not a Drupal newbie, either.
It is precisely those jobs that we’re trying to funnel into a one-click easy install for a Community Operator. So that made me realize exactly what I think we should be doing for Gnomepal, right now. In essence, we are building an easily deployable and maintainable platform for potential community owners. Gnomepal should be the grease of the social web.
I think that goal will entail some main focus areas:
Simplify technical install details.
Maybe through better manuals, through rewriting the install interface for non-tech users, and hopefully through automating some more steps. Also we should add some easy ‘click here for X’ steps pertaining to building a community website.
Simplify the admin interface
The Drupal admin interface is based on giving access to all options of all the different modules. It has to be: a cold drupal install doesn’t know what modules will be installed. But in Gnomepal, we know exactly what modules will be installed. So we can turn the admin on its head and create an interface that is NOT based on all the technical possibilities, in INSTEAD on different things a Community Operator might want to do.
I’m thinking of a main admin page that says:
“Welcome to your Drupal installation. Choose one of these options:
1. Wiki (on/off/wiki options)
“currently you do not have a wiki deployed. click here to turn on your wiki. click here to edit wiki options.”
2. Content voting (on/off/voting options)
“you have content voting enabled. click here to turn off content voting. click here to edit voting options.”
3. Newsletter
etc. you get the idea.
When you go to an options page there will be a small number of easy to understand options. So not all possibilities for every possible community, but a small number of options that work, that are sleek and that will be enough for 90% of all situations. It will hide any modules and their technical details.
Basically: we need an interface to hide the interface. I think this could be one new module (mind you: I’m no Drupal developer), but it will interface with many other modules. It should be a framework that will allow for easy expansion with new Gnomepal features - while hiding complexity from the community operator.
Combine the different ’social” features in sets.
Combine and simplify these. Be very Apple like with buttons that can be used to change things: limit the options. If people want more control or different features: let them study drupal and the modules. If people just want a community quickly and easily: use Gnomepal. Give them many features (and make those logical and beautiful) but only a few options.
So for instance when looking at the Wiki/voting/newsletter/~insert name of integrated feature set here~:
1. What should a Wiki always do?
2. What will we let the community operator turn on and off, or modify?
So we’ll build the features into gnomepal. That’s step one and it’s the easiest step.
Then we have to determine which options to expose to the community owner, based on our knowledge of most often used things.
Then we have to build this into the new admin interface I described before.
For a first build, having the features of wiki, user profiles and maybe one more thing seems quite enough to me. The challenge after all is not building lots of features. The main challenge for this build is: creating a framework for an understandable admin interface. After that we can start to build a new and better feature set.
Create awesome looking themes
And make sure that a theme in version X of Gnomepal works well and looks well with the included feature set. No more - no less.
Have a board of advisors
I agree strongly with Chris’ assertion that we need strong project management. However, I also think there should be some kind of board of advisors to give direction to the project. A well formed board could be a source of community engagement and activation, continued exposure, and a sense of direction for features and priorities. So get, for instance:
- A high profile community operator, preferably working with Drupal (-> Leo Laporte)
- A lesser known community operator with a smaller but active community (Red Room?)
- A insider from the Drupal Community (ask Dries to recommend someone)
- Someone from the Dev Team (Adam?)
- Someone with experience in Open Source Team Efforts
The project manager can have the board convene twice a year, wine them and dine them and have them discuss at will where Gnomepal is going - where it should be going. Write up the discussion and open it up for all to see. Discuss. Narrow down. Focus.
And that…is my 2/100th of a Euro.
Subscribe to this blog
