OpenWack Community Software Blog

While development we use technical specifications for writing code with schemas, drawings, sketches and text. Tomorrow we start laying down proper documentation based on the references we use ourselves.

We realize that some things change right on the road and we will have to rewrite some parts together with the code but the absolute majority of this material is going to stay there. We want to keep this process running along the development because of 2 reasons:

1) It’s just much easier to contribute to documentation writing in small parts using our own references and putting for you what have been magically turned into working code. So it’s not like a damned abyss of work to write the whole thing when the fun part (development) is done.

2) You will have complete reference in the end because it’s being forged right on the dev assembly line and covers particularly anything that is being actually developed.

We understand that nobody wants to read manuals and that is why we will do everything to make it not critical for you to start using/developing for OpenWack. On the other hand, any open source project needs to have sufficient technical reference and manuals to attract rock-star plugin developers. Who is going to dedicate their time to your project if you can’t even describe it properly? We are definitely determined to avoid this question. ;)

Update: We have set up documentation wiki here: docs.openwack.org. This is what will be used by the development team and later by plugin developers and theme designers. Watch it getting filled with the documentation, references, specifications and howtos.

It’s been one month since we mentioned something called “OpenWack 0.0000002314″. Today I’m happy to say we are working with OpenWack v.0.00001. The idea is the less zeros we have after the comma in version number the closer you are to grabbing v0.1 – the initial public OpenWack release scheduled for summer.

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!

Everyone of you saw those fancy labels on sites and software products indicating that the page markup passed W3C validation.

Hereby I claim that W3C validation will not be the priority of OpenWack pages markup nor will it ever be a requirement for OpenWack themes and plugins.

W3C standards were introduced with a good idea of validating HTML and CSS to be supported by all generally available browsers. But the reality is that they bring unnecessary restrictions and do not guarantee anything.

For example, putting block elements in <a> will not validate. Tag <object> (for a flash video player e.g.) will not validate. Although both those examples are handled fine by all relevant web-browsers of today. Why restrict then? These are examples of XHTML Transitional, I’m not even speaking of XHTML Strict.

On the other hand you can write W3C compliant code but there’s no guarantee that it will work in IE7 or (oh god) in IE6. It’s absolutely necessary to test your code in these browsers and even write some CSS hacks to handle their misbehavior. Microsoft did a great job of creating this mess.

I understand why software like Adobe Dreamweaver will generate W3C-compliant markup at all costs. This is marketing and is aimed at people who know what W3C validation is but are not aware of its failure. So realistically for now these are just labels. And they significantly contributed to the wide adoption of the standards that fail to bring the order.

We will try to maintain those standards wherever reasonable but not for the sole purpose of staying compliant with them. Given the mentioned shortcomings we do not see big reasons to comply.

There’s a much more effective practice of just testing all your markup in all major browsers people use. That’s the only relevant validation you can get to write software aimed at providing adequate user experience.

During the first months of planning and development we’ve elaborated the detailed picture of our goals with the OpenWack product and what it will try to achieve in the Web. I tried to formulate a short description of the main points that you can now read, evaluate and ask questions about.

We welcome any feedback on how our mission speaks to you and what we can do to serve your needs better.

OpenWack Mission Statement

We currently work on the engine of HTTP forms for OpenWack core that will be used everywhere: on the user pages, admin area, and plugins. Needless to say, it’s an important task to make forms as easy to operate as possible meanwhile retaining flexibility.

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.

We are passing by the controller-action-view chain in the development process and are moving on to display mechanisms that will render pages and page components.

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? ;)

We are actively developing all the technical backend plumbing for OpenWack but that doesn’t stop us from working on general user interfaces.

The sketching includes thinking over user interfaces, creating real mock-up pages, testing out usability from several perspectives, and getting feedback on final versions. Before the real code is written. This is the way we design web software and we believe it can’t be any other way. If your product is for end users, you gotta start with them, too.

Earlier we posted and explained admin area screenshots on WackWorld now it’s time for some user interfaces.

Here’s the screenshot of a user profile page sketch:

Feel free to comment and ask questions regarding this preview. Also, there’s no better time for suggestions than now, believe me.

We will be posting more screenshots of the UI to tease you while you are waiting for the general availability of OpenWack social network software.

P.S. This is the default theme that is made minimalistic and ascetic on purpose. I’m going to get to OpenWack theming and design later on, it’s a different story.

After debates we decided that the new OpenWack will require PHP mbstring extension.

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.

So, you’ve read all the willy-nilly about the new software and wonder what’s in it for you? I’m going to try to answer this straight question. For that I will define several important points about the software: Continue reading »

Nice to see you here, on the blog about OpenWack software product… even while there’s no product yet. Until that point we are going to share some thoughts and decisions we make during the development period. What better time to express your opinion before it’s too late ;)

So if for some reason you are not one of the 5 people who care about this project at this moment – feel free to say hi and to participate. We hope to build good software for you.

Thanks.