SnipSnap Developing: Trying to settle a roadmap

SnipSnap Developing: Trying to settle a roadmap

Even though I've been away mostly due to the amount of work (and also some compulsive geocaching) I've been working on some of the improvements I planned for SnipSnap. In my opinion I haven't, yet, reached a development milestone but things are getting close. In my last SnipSnap seveloping spree I've finished some of the things that were in the todo list for a long time.

While adding the latest features to my_snipsnap_fork_feature_list I noticed that besides what is presented in that list, I've never written anything else regarding the improvements. The problem with that list, is that it's just a list, and some of the items listed there, need configuration to work… So I decided to list some of the features explaining their configuration, the last item is the newest one - and probably one of the most exciting also - never yet documented.
I'm aware that this won't be interesting for everyone but, I hope some might find use for it.

Features Description

• Social Web configuration: Maybe the name isn't the best, and any suggestions is always welcome. A Social Web Link is a an icon in the top right corner of the post that links to something. It can be digg, delicious or it can be the RSS feed for the comments.
  

Property In Config Snip	Description
app.configuration.socialWeb	contains the identifiers to generate the links. Values are comma separated
app.configuration.NAME.link	name is one of the identifieds listed in the previous property. The Snip is available in the context has a bean, so if in the link there's the need to use the snips name or url it can be simply refereed as ${name} and ${url}
app.configuration.NAME.image	the icon that will be displayed

• Integration with feedburner: this feature allows the user to integrate SnipSnap with an existence feedburner account. The property app.feed needs to be configured with the feedburner's feed.
• Integration with Google's WebMasters Account: The verification with meta-data has to be selected and then after receiving the keyword given by Google configure the property app.google.webmasters.verification.code with it.
• Integration with Google Analytics: After registering in Google Analytics the user code has to be configured into the app.google.analytics.account property.
• Integration with SnapPreview: Some love SnapPreview others hate it, just in case someone using SnipSnap wants to use it, there is now support. To use it, simply register at the service and then setup the app.feature.snapPreview.userKey property with the user key.
• Snip permissions: Finally I've implemented a basic configurable permission system per snip. When accessing a Snip if the user is an administrator or the owner of the snip is able to configure the snips permissions. The syntax is simple, the value is one or more "Permission_Type:Role" comma separated.

Type	Values
Permission	View, Edit, Attach, Post
Role	Owner, Admin, Authenticated, Guest

But the permission setup isn't the only new feature, other new features are the user experience improvement in the search macro, fixing the annoying bug that prevented snips from 31 December to show up, the configuration of snip owner's comments through CSS, there's a pull quote macro - which can be seen in action below - a new version for the CollapsingBlock macro that now keeps state via cookies, a shoutbox system and a better support for multipart requests, which were giving a few troubles in browsers such as Safari 3.0.3.

The RoadMap

Establishing a roadmap is something a bit difficult to me, since SnipSnap is a side project, sometimes I may be months without actually creating something… Still I like to have objectives to pursue.

In the top priority are the following features:

• Improved Access Control, in order to define users and group of users instead of only roles.
• Allowing anonymous posts, after all almost every blog platform nowadays allows that, I don't see why SnipSnap shouldn't allow it.
• Creating a good support for integration with AJAX components.
• Create interfaces for configuring the features listed in features description.

In my opinion the best thing would be to have the complete SnipSnap developing team working in this, although, I don't know anything from them since about a month ago I got an email from Angelo… It's just bad when there is no communication at all.

I don't know how SnipSnap will evolve, I can't guarantee it's longevity nor developing since I'm not the project administrator, but I can guarantee that in my fork, and that's what I'm doing right now. My fork will continue, until I feel there is no use for it.

I really hope things with the reactivation of SnipSnap go well, the project has plenty of potential and I think a good work can be done. Although, in order for that to happen, is needed that everyone wants to improve SnipSnap and even more important, believe that something can be done in order to help SnipSnap.