Since all the fun can now be tracked at WackWall you might find it interesting how we approach bug fixing at the moment.

Look who’s round the corner? OpenWack dev team with that fire of determination in the eyes!

Starting from today we will be doing a series of dev marathons — a well known way of developing software in Skalfa — meaning creating multi-hour chunks of time for the programmers with zero distractions from writing software. You know how it’s done — when a team of bright people works on one big task in the chaotic zen environment. I’m so glad that in the 5-year old company we still like to get our hands dirty and to act startup.

This means that we are seeing that red finish line on the horizon. We have agreed on all essential nodes architecture and implemented the skeleton so everyone in the team gets down to the hard work of building out details. We make 5-minute briefings every hour or so to stay in touch, correct the course, and swim further rapidly.

You want details? We have them for you!

Starting from this very minute we’ll be giving real-time Twitter updates as to what what’s going on in our SVN. We are not by far setting dates for betas or RCs but this stuff will be interesting for dev-savvy users. Read our updates here: Twitter.com/OpenWack.

P.S. No, this is not our team on the picture, calm down.

OpenWack will be available for free download in winter ‘09-10.

We decided to first test the new platform on our own projects (read WackWall and the family). This will let us debug it to death, get details straight, and add all plan-minimum features.

For OpenWack we will also develop all necessary infrastructure for plugin developers, theme designers and users before putting it for download.

This way we want to release something already capable of helping people accomplish their goals. It will save a lot of precious time for users and developers. Once you rely on the platform you don’t need to completely rewrite (or abandon) your efforts. To make it possible we’re gonna take all the real-life fire ourselves first.

We have seen companies releasing half-assed software. Then debug it for months/years or releasing new versions with completely changed APIs to make everyone adopt. Somebody calls that the only proper way to develop software. But we are the crowd that never opts for the obvious.

We will test the software on paid projects before open-sourcing it.

We’ve “been there, done that” before. All OpenWack is about is putting our industry and business logic experience from other projects into the most efficient technical form possible. The one that we’ve been crafting for 7 years. The mere fact that all future Skalfa products will be based on this platform makes us work really hard to show the world something that can be relied on during the whole lifetime of a community project.

Watch news, and watch WackWall update in October.

Our work recently consists of sketching features and laying down business and technical specifications for them. We found this as the most effective way to write software. Development (coding) itself is a rather straighforward and quick process when you have specifications and exact user interfaces for your work.

Anyways, this critical part of the product development is consuming more time than we originally estimated. This is primarily because we have insight in the business logic (thanks to our 5 year experience with SkaDate) and a lot of system components and classes are being laid down before any actual features.

Of course we could go the startup way – build underfeatured and shortsighted version 1.0 quickly and see how people react to it. In our case we’ve got substantial experience of building community sites for people so we have a great idea of what it takes. Specifically we project the software having in mind anything that will be necessary later. This approach is more consistent and is only possible when you have exhausting business logic details.

As for coding we are building languages and profile questions business layers and user interfaces.

What’s coming?
First of all we agreed to write full specifications for the current WackWall functionality so we can relaunch it and continue to quickly add functionality. Together with that we will start building infrastructure for OpenWack.org and put the software for download some time later. At this point I can’t provide any dates. We try not to make ourselves hurry too much.

Internet Explorer 6, an ugly creature – you can wrap up in a white shroud and crawl to the graveyard where you belong. The reason you are still undead is another big Microsoft failure – Windows Vista. If people did not snatch at their non-upgraded Windows XP copies IE6 would be long gone.

I think IE6 problems are well-documented on the web by designers so I’ll spare you the rhetoric. Default theme for OpenWack will not support IE6.

At this point we have DB structure and interfaces, theme engine, forms engine, and a rudimentary plugin system. Currently the developers finish database interfaces, DAOs and DTOs; interfaces designers lay out default theme (that will always be used in admin area).

Some time this week we will move on to tangible functionality – admin pages and forms. It’s exciting to see the dev process iterate to the funny and actual stuff. Especially since we declared our commitment to create something good. We may have some sneak peek screenshots for you down the road.

Watch news!

For example, 80% of admin area will consist of forms in their basic incarnation, such as listing sectioned fields of settings with “Submit” button. On the other hand plugins may require all kinds of forms, response types, before-submit validations and all.

A basic form is going to have default decorator. This can be overridden right in the markup if your form requires that. Also you will be given program tools to control submit methods, Ajax, validation, and so on.

Forms, as a critical part of the OpenWack core is most likely to have several iterations through the product versions to mature but at this point we have a very good understanding of their requirements. We have seen them all with other Skalfa products. OpenWack will contain all technical experience of the company and introduce our understanding of the current and future community software market.

During these 7 years that I’ve been producing community software there were two main requirements: robustness and insane flexibility. OpenWack as an open source social networking software is not an exception. We defined several important points that OpenWack theming must meet:

• Speed and easiness of creating new themes
• Easiness of maintaining and upgrading themes
• Easiness of maintaining integrated look’n'feel throughout the vast 3rd party functionality

For display customization tools:

• Possibility to move around elements within and between pages
• Possibility to add custom pages with custom and existing elements from plugins.
• Possibility to edit existing pages (even created by plugins) and add custom and existing elements from other plugins

Our team has intense discussions at what theming and customization approach would be sufficient for open source software with an unlimited range of functionality.

We have a serious task of dividing the markup and styles of everything into independent and mobile pieces to get the right balance of flexibility and ease of creation and maintenance.

Here is the descending chain of information display that needs to be customized at each node:

Main CSS -> Masterpage -> Page template -> Component -> Decorator

1) Main CSS
This is the main CSS stylesheet provided by a theme. It implements general styles for colors, fonts, graphics, buttons and all general website elements.

2) Masterpages
These are markup patterns also implemented by a theme. For example, your site has standard header, footer, and sidebar while your index page is custom – has no sidebar and its header contains promotional graphics and banners. Here you have 2 masterpages (e.g. “general” and “index”) that will serve as envelopes with a big white hole instead of the actual page content.

3) Page templates
They are a number of standard page layouts implemented by OpenWack core and plugins that describe sectioned markup with components that the page contains.

Here’s an example of markup for a page template of 2 columns with a list of new members and a welcome message (Warning: Actual OpenWack code may be different.)


<div class="left supernarrow small stdmargin">
{component type="latest_members" decorator="list_picture_content" data=$latest_members_data}
</div>

<div class="right superwide stdmargin">
{component type="message" data=$welcome_message}
</div>


This is a page template for site index page. Mailbox or forum topic page will have different layout and different components on them. You can edit templates of the custom pages you create and also pages that are created by plugins. Put an invitation box for the upcoming community event on photo list page so nobody misses.

4) Components

Components (as shown in Page templates section) are obejcts that show pieces of information all over the place on your site. All pages can be seen as placeholders of components of different purpose (comment list, input form, latest photos, mailbox message, etc…) and look (boxes, highlighted boxes, images, pieces of text, list of images, controls and inputs). Components are created by core, by plugins, and some basic ones (text, image, RSS) by site editors.

5) Decorators

Decorators are mainly templates for components with specific CSS and JavaScript. Every component must use a decorator, and different components can use one decorator as a way to display content. Recent blog posts, video and photo comments, a list of latest forum topics will all use one decorator that will display a profile avatar, header information (e.g. post title), and content.

Thus a number of decorators (around 20) will be provided by the core for hundreds of possible components implemented by tens of possible plugins. Sure there will be a moment when none of the existing decorators will fit your custom component – feel free to create your own with a template, CSS, and JavaScript. This is why decorators must be independent and mobile.

Each theme can override default decorator markup, so by creating new decorator templates you can customize your theme so nobody even recognizes OpenWack software behind your site. And this is as easy as creating several decorator templates with little amount of markup.

CSS styling of decorators should of course comply with the main theme CSS to just add customized elements or override some of the standard ones, not describe decorators from scratch. Since decorators are universal and can be created by plugins without theme context
they should maintain a good standard of markup and CSS compliance. Careful creating new decorators means better display and easiness of theme mantenance.

Conclusion

With this chain of customizable nodes descending from pages to the basic bits of information displayed on your site you have the benefit of integrated look’n'feel throughout the site (done by using a few decorators by all components); you can create themes that will be sufficient for all existing and future plugins (if they use best practices); you can quickly and easily clone an existing theme and change it upside down by playing with main CSS stylesheet, masterpages and decorators markup.

We hope this approach is going to provide easy and quick way to create maintainable themes while not sacrificing the flexibility and freedom of content and design. If you have any feedback on the offered model feel free to comment and share your ideas.

P.S. Ah, I forgot to add that we need to make it possible to do all this customization via admin panel, without messing with files, because we need to give WackWall free social networks the same level of control. Didn’t I mention that our mission is difficult and interesting? ;)

The problem is that mbstring is not widely supported by hosting providers. A lot of software packages _recommend_ having mbstring and in case of its absense create various semi-correct wrappers for string functions emulating multi-byte support. This is not the thing we want to do, so looks like we have no other option than including mbstring into hosting requirements.

We think that it is critical for PHP string functions to work properly that is why you will need to find a hosting provider that supports mbstring. You can always check our hosting recommendations.