Collab.js 0.4.0 is out

I’m glad to announce that a new version of collab.js (0.4.0) has been released today.

The build focuses on the following features:

  • Angular.js as the core client-side framework
  • Migration to Bootstrap 3.0.3
  • Upgrade of Font Awesome to version 4.0.3
  • SSL support
  • New card layout for user posts
  • Development process enhancements (configurations for JSHint, Grunt, Karma, etc)

Please refer to release notes for the full list of features and enhancements.

Card layout

With version 0.4.0 collab.js introduces card layout for user posts instead of a plain single-column list. New layout is highly responsive and automatically changes amount of columns based on available screen size. For example on large widescreen displays users may get 4 or more columns, 3 columns on tablets and single column on smartphones.


click to enlarge


Inline comments

All comments are displayed inline and are updated every time user expands corresponding area. Every card automatically enlarges and shrinks upon comments being toggled. For large amount of entries a scrollbar is enabled:


Contextual options

Every card entry has a menu with contextual options. It gets displayed as soon as user hovers mouse cursor over the card and provides access to various options.

Context menu

As of version 0.4.0 only ‘Mute post’ action is available for end users. The list of available commands will keep expanding within upcoming versions of collab.js.

Context Menu

New ‘Login’ and ‘Sign Up’ pages

Version 0.4.0 features completely new mobile-friendly ‘Login’ and ‘Sign Up’ pages.


Sign Up

Menu bar enhancements

With version 0.4.0 global sidebar element has been deprecated in favor of top menu bar that is more efficient when running collab.js on smaller screens (i.e. tablets or smartphones). Menu bar got better selection indication, access to search lists (dynamically updated dropdown menu) and enhanced settings menu:

Search Lists

Settings Menu


There was also a set of development process enhancements:

  • Grunt task runner support (used to minify CSS files, also performs minification and concatenation of JS files for production mode)
  • Custom JSHint configuration (used to share JSHint settings when using multiple platforms for testing and development)
  • Karma test runner configuration (initial configuration required to run client-side tests)

Full source code can be found here.


Setting up OpenShift Origin Virtual Machine on Windows 7


This article describes the process of setting up a VM running OpenShift development environment inside VirtualBox on Windows 7. The article was inspired by the “OpenShift Origin Virtual Machine Deployment Guide“, it borrows some information from the guide but concentrates on Windows 7 as a host and development machine and addresses various issues that a Windows developer may come across (and not covered by the original guide).

I am going to dwell on the following aspects:

  • Setting up the Virtual Machine
  • Network configuration
  • Accessing the Virtual Machine
  • Accessing deployed application from the Windows host
  • Using RHC tools with multiple servers
  • Port forwarding
  • Accessing deployed databases from host machine

Setting up the Virtual Machine

Download the VM from the OpenShift “mirrors” site (about 1.3 GB): 

Unpack the package with your favorite .zip manager. This can take quite a while. The result will be the creation of four additional files (file sizes may vary):


Create New VM

You are going to create a new Linux machine with Fedora (64 bit)


Set VM Memory Size

Set the memory size to something reasonably large. 1 GB should be a good start. Later on you can give your machine more memory depending on cartridges used.


Select VM “Hard Drive” Image

For this step you will need to select the virtual disk image (you’ve unpacked earlier) which contains the OpenShift Origin virtual machine.


Network configuration

By default VirtualBox uses Network Address Translation (NAT) to create a virtual network interface for your virtual machines. NAT will not let you connect back into your virtual machine. You need to change the network adapter configuration to use Bridged networking. Then you virtual machine will get an IP address from your DHCP server, and you will be able to use that address to browse or log in.


Each system may have different names for the network adapter. Find yours in the pulldown menu labeled “Name”. Select it and press the OK button. You’ll return to the main display ready to start the VM.

When the VM has completed booting VirtualBox will display the access information for the VM and prompt you to start a root console.


Please remember the IP address VM has obtained (i.e. as you will need it in order to access OpenShift Console. More details on IP/URL address configuration and will be given later in this article.

Accessing the Virtual Machine

When VM is running it is accessible from the host machine either using OpenShift console via a web browser or on a command line interface using SSH. The web interface is useful for easily managing applications while the CLI allows developers to write and test applications and components. The web browser will also be used to verify the test applications during development.

User Accounts

There are two user accounts which are used to access the OpenShift Origin VM. Both are displayed on the VM console when it boots as shown in the examples above.

The first one is the OpenShift service account. This is used to access the web console and run the rhc CLI commands as a developer.

  • Username: admin
  • Password: admin

The second account is the developer account. This is a UNIX account which is used to log into the OpenShift VM via SSH. It provides a work space for exploring the CLI and development environment of OpenShift Origin.

  • Username:  openshift
  • Password: openshift

If you try logging in with one or those and it fails, try using the other.

Using a browser to view the OpenShift Console

When the VM is running you can use the OpenShift console to create and manage applications in the VM. Navigate your browser to the IP address the VM machine has automatically received during boot (i.e. Enter the username and password (admin/admin) when prompted.


Using SSH to log into the VM

Most of the OpenShift workflow for application development is done from the command line. The OpenShift VM has account created and populated with the tools needed to create, manage and develop apps for demonstration purposes.

Developers may reach the command line on the VM using SSH from the host.  The easiest way of using SSH on Windows machines is by Git for Windows bash.


At this point you are going to use IP address of the Virtual Machine for SSH access. When prompted for the password use ‘openshift’ one.

Accessing deployed application from the Windows host

For demonstration purposes I have created a basic ‘Node.js 0.10’ application named ‘Test01‘ having namespace ‘dvuyka‘ like shown below


When application is created you will see an entry within ‘My Applications’ area with a URL having the following format:


However by default on Windows hosts you won’t be able accessing your application with the browser because of DNS resolving. The easiest and quickest way solving this issue would be changing the hosts file and providing required addresses explicitly. This will allow saving time on DNS server configuration especially when working offline or with isolated environment.

Setting up hosts

For more information on modifying ‘hosts’ file on Windows please refer to the following article:

How do I modify my hots file?

You will need at least 3 entries to be explicitly declared, 2 for OpenShift environment and 1 for your application: openshift.local broker.openshift.local test01-dvuyka.openshift.local

Typically you will need mapping every application endpoint to be accessible. There is no need rebooting Windows after making change to ‘hosts’ file.

Now you should be able accessing OpenShift Console via https://openshift.local address


Clicking the application URL will now allow you accessing deployed application from within your Windows host browser:


Using SSH to log into VM

At this point it should be possible using broker.openshift.local address with SSH connections:


Configuring static IP address for VM (optional)

The only problem with ‘hosts’ file approach mentioned above is DHCP configuration. After reboot the OpenShift Origin Virtual Machine make obtain different IP address from DHCP server and all host mappings won’t be working. In order to solve this issue developers may want providing a static for VM to ensure IP address is always the same.

I will be using ‘nano’ editor for the sake of simplicity

sudo yum install nano
nano /etc/sysconfig/network-scripts/ifcfg-eth0

You will need to change the BOOTPROTO value from dhcp to static and providing explicit values for IPADDR, NETMASK, NETWORK and GATEWAY depending on your network/router configurations


As soon as you have finished editing the file press “Ctrl+O, Enter” to save the file and “Ctrl+X” to exit. Server needs to be rebooted after that.

sudo reboot

Now as per configuration above my VM will always be starting with address.

Using RHC tools with multiple servers

It is possible switching between different servers with RHC tools. Having multiple server configurations allow working with both local and remote environments. In order to create new configuration for your OpenShift Origin VM you will need executing the following commands with Windows command prompt:

rhc setup --server openshift.local

This will RHC tools creating additional configuration called “origin” pointing to your “openshift.local” VM

In order to use “origin” server configuration the “OPENSHIFT_CONFIG” environment variable should be defined before invoking RHC tools next time:

rhc <command>

Configuring RHC tools with OpenShift Origin VM will allow using Port Forwarding and accessing your applications and databases from within Windows host.

Port Forwarding

With OpenShift port forwarding, developers are now able to connect to their remote services while using local client tools without having to worry about the details of configuring complicated firewall rules.

For more details on port forwarding feature please refer to the following article:

Getting Started with Port Forwarding on OpenShift

Accessing deployed application from Windows host

With Windows (or Visual Studio) command prompt you can setup port forwarding to your VM

rhc port-forward -a test01


While command prompt is running the deployed application can be accessed via local loopback address:


Accessing deployed database from Windows host (MongoDB)

When port forwarding is started RHC tools automatically detect all ports to be wired. That applies to database cartridges as well. Examples below will be based on ‘MongoDB’ cartridge.

Add database cartridge

In the OpenShift web console navigate to your ‘Test01’ application and add ‘MongoDB NoSQL Database 2.2’ cartridge



Don’t forget to write down credentials somewhere as OpenShift Console does not expose them after cartridge is created.

You can get more details on OpenShift support for MongoDB here:

MongoDB on OpenShift

Start port forwarding

Once database cartridge is added you can start port forwarding with Windows or Visual Studio command prompt

rhc port-forward -a test01

You should see multiple ports now:


Connect to database

In order to connect to Mongo database I will be using Robomongo for Windows.


For the authentication section please use credentials you got after having created MongoDB cartridge


It is now possible working with your MongoDB database directly from Windows host


Using Git publishing with VM

There are no specific steps required to enable Git support for OpenShift Origin VM once the Windows environment is configured.


Please refer to the following articles if you want getting more information about Git in the scope of OpenShift

Deploying and building your applications
Accessing your code for your OpenShift Application via Windows Explorer using TortoiseGit
Authentication and SSH Keys


The steps above allow a developer to download and run a self-contained OpenShift service for development or demonstration purposes. The service runs in a VirtualBox virtual machine and is accessible to the user on the host machine running Windows 7 and is accessible to the developer by means of VirtualBox graphical console, by SSH or with a local web browser to access the OpenShift console and/or any applications that are created within the OpenShift service.

Announcing Masonry for node.js

I’m happy to announce that node.js version of ‘Masonry’ framework (branded as collab.js) has landed it’s GitHub repository.

Masonry is a starter kit for social-enabled web applications. To get more details about Masonry starter kit for ASP.NET MVC4 please refer to the following article.

Supported environments

Masonry.js supports both OSX and Windows development environments. In addition it contains support for Microsoft WebMatrix 2 for development and deployment/publishing, and uses only those NPM modules that do not require manual compilation steps in order to run on either OSX x64 or Windows 7 x64 systems.

Supported databases

Masonry.js features extensible provider-based model for data layer. It is extremely easy writing custom data providers or switching between them. At the moment of writing this article the following database engines are supported out-of-box:

  • Microsoft SQL Server
  • MySQL Server

Providers for Azure SQL, MongoDb and SQLite are in progress and will appear pretty soon.

Simple code maintenance

The Node.js version of Masonry provides a better code partitioning with the benefit of keeping the core implementation and modules up-to-date with less effort. Masonry views, routes and controllers are kept separately to avoid interference with your development process.

Great level of extensibility

With node.js and JavaScript you get extensibility for nearly everything out of box. With node.js you don’t need binary compilation of the project and so don’t need complex plugin layers with always limited APIs for discovery and initialization of extensions at run time.

In order to reduce the need modifying core Masonry files there is a set of lightweight contracts (via configuration files) to modify or extend key parts of the UI like brand/copyright information, sidebar/header links, etc. That means less time can be spent to keep Masonry up-to-date and more time for your own features.

Separate presentation and web api layers

The frontend is separated with a plain presentation layer and web api’s – set of RESTful services with JSON output by default. It becomes extremely easy switching between presentation layers and rendering engines, or building  completely different clients on the top of existing RESTful endpoints.

And many more…

You should expect more features and details soon. Meanwhile feel free raising issues and/or suggestions here.

Simple Workflow Designer with Silverlight and MEF

Introducing simple workflow designer

I’m excited to announce another project from my collection went public today. This time it is a demo POC (proof of concept) implementation for a simple workflow designer written in Silverlight 4 and MEF.


The project contains the following features that may be interesting for review:

  • Design surface with drag and drop (MVC)
  • Toolbox with automatic runtime discovery of items (MVVM)
  • Drawing connections, live update of connections during drag and drop
  • Separate model layer with custom serialization support (functions, activities, workflows)
  • Separate presentation layer (visual elements for activities), styling and templating nodes
  • Runtime discovery of models and corresponding node views (decoupled layers)
  • Simple rules (i.e. “Output ” node may have only 1 incoming connection)

There are two modes supported out of box – Design and Source views.

Design view

This mode showcases the process of visual modeling. The process is divided into two separated areas – Toolbox and Design Surface.


Toolbox hosts all items exported and discovered at runtime by means of MEF. Default set of activities resides in a separate “WorkflowDesigner.Activities.dll” assembly and can be easily replaced or extended. There’s also an additional “WorkflowDesigner.Sdk.dll” assembly that is mean to be shared across 3rd party libraries and aids in creating custom activity libraries.

You can add activities to the surface by double-clicking the corresponding item in the toolbox. For the sake of simplicity there is no drag and drop support for the toolbox but it can be easily introduced. The quickest way may be reusing Telerik’s drag and drop manager with fancy visual cues, but this is out of scope of this article.

Design surface is based on MVC pattern and showcases basic set of functions like: drag and drop of activities across the surface, drawing connection lines, removing nodes or connections, clearing entire surface. Every visual node is mapped to underlying model (activity) at runtime. That means that both activity and it’s visual representation are completely decoupled and any of the parts can be easily tuned or extended.

For demonstration purposes default activities emulate the behavior of OData- or SQL-based entities with simple UI editors, entire project emulates the process of creating a workflow that deals with data aggregation.


UI dialogs are not bound to any particular business logic except assigning corresponding property values of the model entity. However this may be a good start building user experiences based on your real-life scenarios.



Source view

In addition the Source view feature is supported. It allows you switching to the XML representation of the workflow at any time during design process. Serialization is completely custom and was kept as simple as possible in order to be replaceable or customized. Based on your real-life scenarios the resulting XML can travel to server side and can be turned into object graph without UI dependencies, etc.


Project structure

I will be giving only brief overview of the project structure in this article. Most of the code is split into 2 areas and resides in 2 different class libraries: “WorkflowDesigner.Sdk” and “WorkflowDesigner.Activities“:



As soon as you figure out the process of creation of new activities you most probably may need only “WorkflowDesigner.Sdk” assembly that contains all core and shared functionality.

Source code

You can grab the source code at my GitHub repository.

Masonry Extensibility. Part 1.

This is a second post in a series of articles about Masonry starter kit. Please refer to this article in order to get more information about Masonry:

Announcing Masonry public preview

Masonry starter kit was designed with extensibility in mind from the very beginning. There are several out-of-box blocks that greatly reduce learning curve and efforts required to extend main navigation elements like sidebar and header bar, provide custom content and routing, integrate into help or search system or messaging pipeline.

Masonry is also shipped with a project template for Visual Studio 2012 that turns the process of extension library creation into a several mouse-click procedure.

Part 1 of this article will give a high-level overview of supported extensibility features as well as developer tools shipped with version 1.0

Part 2 will dwell on technical details of extension discovery, processing and mapping of dynamic/static content and UI composition.

Extensions in Masonry are based on Areas that are compiled into a single-assembly libraries and deployed to Masonry-based web application by means of xcopy. For more details on Areas in ASP.NET MVC please refer to the following articles:

Walkthrough: Organizing an ASP.NET MVC Application using Areas

ASP.NET MVC Areas – A Better Way to Structure The Application

Using Areas in ASP.NET MVC Application

Every Masonry extension depends on the following assemblies:

  • Masonry.Core.dll (required)contains low-level infrastructure required by Masonry and 3rd party extensions in order to function.
  • Masonry.Extensibility.dll (required)contains shared blocks that may be used by all or any 3rd party extension. For the moment of writing this article it consists mainly of UI-relacted contracts.
  • Masonry.Resources.dll (optional)contains default localized content that may be reused within extensions

Masonry does not require extra efforts in order to enable extensibility support for a web application, referencing “Masonry.Core” is usually enough to automatically enable underlying infrastructure.

There are two different modes supported by Masonry out-of-box: automatic (or convention-based) and controlled (or configuration-based) extension discovery.

Automatic extension discovery

This is the default mode and requires zero coding efforts besides referencing “Masonry.Core” assembly from within your Masonry-based web application.

Prior to web application startup the following workflow is executed automatically:

  • Underlying extensibility engine is initialized and started
  • All assemblies are discovered by “*.Extension.dll” mask and loaded
  • Custom ASP.NET MVC view and content providers (Masonry-specific) are initialized and wired with the extension libraries if loaded with previous step

With automatic discovery mode every 3rd party extension library must follow the following predefined conventions in order to allow resulting assembly to be discovered and loaded:

  • Extension assembly file name should end with “.Extension.dll
  • Default root namespace for the extension assembly should not end with “Extension” word

The process of configuring assembly file name and namespace for a new extension project is pretty simple. For example in order to configure a “Dummy” extension developer may need performing the following steps:

  • Create a .NET class library project named “Dummy” and navigate to project properties pane
  • Ensure “Default namespace” property is set to “Dummy”
  • Change “Assembly name” property from “Dummy” to “Dummy.Extension”


Note: steps above can be omitted when using “Masonry Extension” project template for Visual Studio 2012 shipped with Masonry kit out-of-box. More details regarding project template will be given further in this article.

Controlled extension discovery

Due to security, performance, additional level of extension management and review, or any other reasons it is possible switching off automatic discovery for 3rd party extensions and defining them explicitly within configuration file (web.config) instead.

The following picture demonstrates registration of “Dummy” widget within configuration file:


In this case the following workflow will be executed prior to web application startup:

  • Underlying extensibility engine is initialized and started
  • All assemblies from configuration file are discovered and loaded
  • Custom ASP.NET MVC view and content providers (Masonry-specific) are initialized and wired with the extension libraries loaded during previous step

The are no file and namespace naming conventions for configuration-based mode (as it is possible defining corresponding values within configuration file as well).

Extension project template

In order to greatly simplify development process and reduce amount of efforts and time needed to create and configure a new extension library Masonry is shipped with a special project template for Visual Studio 2012.


Important note: for version 1.0 the resulting project should reside within “Extensions” subfolder of the project like displayed on the picture. This is required in order to automate configuration of assembly references and Nuget packages for a newly created project.

Project template handles and automates development process by executing the following operations:

  • Creates new class library within “Extensions” subfolder
  • Configures all Masonry-related assembly references, wires project with required and/or optional Nuget packages
  • Enables Razor support for newly created project (code highlighting, intellisense, compilation, etc.)
  • Creates initial file structure that conforms to common ASP.NET MVC Areas design
  • Generates “Area Registration” settings for the given project including default route registration
  • Generates set of files that address basic extensibility scenarios, for example sidebar and header bar extensions, grouping, default “main content” and “about” pages, etc.
  • All generated files and automated settings take into account name of project

So upon creating a new project with this template you get a working Masonry Extension library that is ready to be instantly compiled and deployed to main web application.

By default Masonry also provides and embedded demo extension called “Dummy” that reuses most of the extensibility features:


The file structure of the project when using Masonry Extension project template will be nearly the same except the name of the area registration class, all code namespaces and all UI labels/names will be reflecting the name of the project you have defined at the creation stage. This means that multiple extensions created from the same template won’t conflict.


Here’s for example the content of the Area Registration file that was automatically generated for the “MyExtension1” project:


And image below provides a quick example on a sidebar extension element generated automatically and aligned with your project name and settings:


Needless to say that resulting project can be tuned in any way. Visual Studio template just takes care of the most frequent, repetitive and so time-consuming tasks.

Compiling and deploying extensions

Every class library created with “Masonry Extension” project template can be instantly compiled and deployed to a Masonry-based web application without any modifications.

As a result of successful compilation you will be getting a single assembly file with all the features and content required by extension.

Important note: all non-C# files related to ASP.NET MVC (i.e. “.cshtml” files) and static content should be marked as “embedded resources” in order to be included into resulting assembly and processed by Masonry at run time. It is possible including images, JavaScript, CSS, etc. files as embedded resources as well. Masonry will ensure those files are mapped properly during execution and behave as common MVC views or static/script files.

Besides changing build action to “Embedded Resource” developers need performing no actions. Picture below demonstrates the default set of files delivered by Masonry Extension project template as embedded resources:


Deploying compiled extensions has no special requirements or prerequisites. Resulting “.dll” file can be copied into the binaries folder of the target Masonry-based web application. Optionally you can drop debugging information (.pdb files) to enable debugging of deployed extensions and stepping through the code:


Note: when using “controlled discovery mode” you may need defining a new configuration entry upon deploying your extension to the target web application.

Upon execution and extension discovery Masonry will automatically populate sidebar, header bar and other extensible UI areas with corresponding elements. Every action (link) will point to custom extension-provided content.


This is the end of basic overview of extensibility in Masonry. In the second part I will be giving more information about areas that support extensibility in Masonry, classes and contracts that may be utilized when writing custom extensions, technical details on embedded resources and the process of mapping them at run time, and a lot more…

Announcing Masonry public preview

Today I’m happy to announce the public availability of my new project “Masonry”. Please note that this post is a high-level overview of the project and its major features. For the sake of simplicity technical details are omitted. Developer-oriented articles will be published separately.


Social networks and corresponding UI/UX gains more and more attention. Even big enterprise players are looking forward to embedding social and gamification features into their products these days. Most of the projects I’ve been involved with during this year had requirements for lightweight “socialization” of common business workflows, i.e. chats, timelines and data aggregation, comment systems, following/unfollowing, user profiles, etc. Most of the project prototyping I’ve observed or was part of during the year assumed Twitter/Facebook-like user experiences besides mandatory functionality requirements.

Masonry was born as an ASP.NET MVC4 starter kit (or template) to greatly reduce learning curve, time and development efforts required to start prototyping and building social-enabled web applications, or integrating social-enabled features into existing applications. It provides most common building blocks and allows startup or research teams concentrating on main application functionality rather than building social features from scratch.

Home Page


Masonry is not a static template. Many frequently required and expected features are still being researched, analyzed and included into the roadmap. You should expect frequent updates that bring new blocks in the future.

The major set of features shipped with initial beta is as follows:

  • Account registration with email confirmation/validation and reCaptcha support
  • Account settings and password management
  • Timeline and user posts (status updates)
  • Public profiles, following/unfollowing other users
  • Personal feeds and “twitterization” of content (account links, hash tags, etc.)
  • Comment system
  • Mentions and People hubs
  • Wiki-based help system with Markdown support
  • Extensibility support (single-assembly modules built with ASP.NET MVC4 template and deployed with xcopy)

There’s also a supplementary content to aid development:

  • Default demo database to get started instantly (SQL LocalDb)
  • SQL schema scripts to setup a new database
  • Visual Studio 2012 project template for creating custom extensions/modules with less efforts

Account Registration

Account management is built on to of SimpleMembership provider by MS used in most of the WebMatrix projects these days. That allows having more flexible membership scenarios (i.e. support for external OAuth authentication models, Facebook/Twitter/LinkedIn integration without much efforts) and provides greatly refined SQL database schema compared to popular ASP.NET SQL Membership provider.

Registration form prevents cross-site request forgery (CSRF) out of box by utilizing ASP.NET MVC’s AntiForgeryToken helpers.

Google reCaptcha is also preconfigured by default

Account Registration

In addition Masonry supports account validation and email validation. This feature when opted in through configuration allows automatically generating confirmation emails with links to confirm and enable newly created account.

Signing in

Similar to Registration form the LogOn one prevents cross-site request forgery (CSRF) attacks by default. All redirect URL links (used to redirect back to the requested content that requires authentication) are verified to be valid local addresses rather than external links.

Sign In


All authenticated users are automatically redirected to the Timeline. Similar to Twitter it is a long stream showing all Posts from those you have chosen to follow, or your own posts with user comments. There are no paging controls on the Timeline, similar to Facebook new content is downloaded smoothly while you scroll down the page.


All content is “twitterized” by default – all user account tags are turned into user profile links and point to Personal Feeds (see below), all hash tags are wrapped with hyperlinks redirecting to internal Search controller upon click. In addition all hash tags are enumerated in a separate area below the main post content.

There are at least 2 easy ways to post new content (i.e. status update) in Masonry:

  • Inline editor box at the bottom of the Timeline
  • “New Post” button on the header bar and available on any page

Image below demonstrates a dialog that appears when user presses “new post” button:

Status Update

Personal Feeds

Masonry provides support for personal feeds – streams showing public posts by a specific user. There are several ways quickly accessing personal feed:

  • User account name within the post header
  • User account tag within the post or comment content
  • Public profile dialog that pops up upon clicking user avatar
  • People or Mentions hub

Upon navigation the sidebar control will automatically reflect the account opened:

Personal Feed

Public Profile Popups

Masonry automatically wraps all user avatars with profile popups that allow following/unfollowing particular user, navigating to a personal feed or People hub to see followings/followers.

Profile Popup


Similar to Twitter Mentions Masonry provides support for streaming posts that “mention” current user – i.e. any post that has an account tag in the content. All Timeline features like profile popups, comments, personal feed navigation are automatically applied to Mentions stream as well.


People Hub

To simplify intranet/corporate scenarios Masonry provides a special feature “People Hub” that allows newly registered users discovering already existing members (to follow, view personal feeds, etc.). People hub lists existing uses with basic public information (see Account Settings section below) and main statistics like number of posts, followers or users being followed by a particular user. It is possible following/unfollowing users directly from the People hub:

People Hub

Note: it may be possible wiring People hub with additional logic and business rules, like showing/filtering users by department, etc.

Account Settings

Users can access their account and profile settings from the header bar. Besides account editing Settings drop down menu provides access to Help system, About information and allows signing out as shown on the picture below:


There are no mandatory fields within account settings section. All public fields are optional: photo, display name, location, website and bio. If current browser supports HTML5 File API user will be able to preview changes to the picture live without uploading any data to server.

Account Settings

Both “Account settings” and “Change password” forms provide lightweight unobtrusive alerts to indicate update results.

Change Password

Comment system

For extensibility and flexibility purposes Comment system in Masonry is separated from status updates (posts). To avoid user distraction comment areas are collapsed by default:

Generic Post

Moreover comments are loaded asynchronously upon expanding “Comments” area. That reduces initial page memory footprint and speeds up main content loading.

Post Comments

The author of the post has possibility removing posts with corresponding comments:

Removing Posts

Similar to Facebook Masonry supports displaying posts in separate pages. Every post that has more than 10 comments is automatically opened in a separate view.

Help System, Markdown Support

Help system is a separate block within Masonry that provides Wiki-like experience and powered by Markdown syntax.

Help System with Markdown

Underlying Help Controller maps physical “.md” files automatically, it is possible updating Markdown content with a running application:

Help Content

Markdown syntax

Extensibility and Modules

Masonry utilizes Managed Extensibility Framework (MEF) and ASP.NET MVC Areas to provide rich extensibility support. External extensions are discovered and loaded automatically with zero code configuration and prerequisites within main application. All extensions are represented by a single-file assemblies containing a fully-fledged ASP.NET MVC4 pieces together with static content, styleshees and javascript files.

Upon new extension library discovery Masonry automatically augments UI with additional entities taken from the corresponding plugin:


Every custom extension can provide extra elements for header bar (with grouping support), sidebar, may provide user with additional content. With Masonry it becomes extremely easy extending standard UI and functionality.

Dummy Extension

In order to greatly simplify development process Masonry provides a special “Masonry Extension” project template that can be used with Visual Studio 2012. This project template takes care of project structure generation, enables Razor compilation and syntax highlighting for the generated class library project and contains all extensibility/routing settings automatically preconfigured.

Note: there will be a separate article that dives deep into Masonry extensibility, tooling and plugin development. 

That’s pretty it. Feel free to grab the code, play with it, request features that are important, file issues… everything is in the GitHub repository.

Thanks for following.

I’m back to blogging

After a long pause I’m finally back to blogging. This year was a very productive one, I’ve been involved in a series of awesome R&D projects related to Silverlight, ASP.NET MVC, Mono, etc. Lots of material to be turned into useful articles.

During this week there will be an additional announcement for the next big thing from my side – Masonry. That is a starter kit for social-enabled extensible MVC4 applications that enters public preview and going to land into my GitHub repository soon.

More information and posts are on the way.

Thanks for following me.