@Joe Sokohl: Yep – it’s a fancy (make that ‘nuanced’) way to say ‘context’. People in the audience who *aren’t* tired of hearing about ‘context’, please raise your hands. That’s about what I thought.

And If your hand isn’t up, I hope it’s busy holding a glass of good wine!

The important thing about your article is portal vocabulary. I was doing all the design without any language. However, after reading the article I was able to articulate my thoughts in a better way.

I used almost all the concepts you provided in one way or the other. As an IA I was already familiar with all these concepts through experience or exposure. The important thing is that you put them together as a binder which one could refer back to.

In the end, I would say that I like the way you approached portal design. You made it look unified and created sense out of it. Basically, you stitched together the fragments of portal design that were spread all over in my mind and perhaps everybody’s. Thanks for creating this “101 of Portal Design”.

Have you thought about widening the perspective to include all types of website? I am thinking particularly about CMS and how these software solutions affect what can be delivered and the controls content producers have over the visual representation of the pages they maintain. Obviously what they do with a page has a big effect on the user experience but these patterns that you outline here may help to control, or define, the ability to move elements around.

The company I work for are about to purchase a system that will give control over to the website producers, away from the UX team, so they can change the page in an instant. Have you any tips to look out for in terms of user engagement metrics or the monitoring of what they do with the aim to not disturb the user experience?

CMS is definitely an arena with good potential for applying the blocks. Social media and rich interactions are others, but we’re not focused on those at the moment. In CMS efforts, the blocks can help bridge the customary mental fault line separating content creation vs. content distribution. It’s an outdated framing that adversely affects the basic model for much CMS work at all levels of size and complexity, not just the enterprise realm. [See Dan Brown's http://www.greenonions.com/archives/2005/06/24/content-managements-inevitable-conclusions/ for a start on this...]

Would you mind sharing some of the things you’re working on / thinking about related to CMS and building blocks?

If your company is tracking any of the common business metrics (for customer satisfaction, time to market, product sales, revenue vs. expenses, effectiveness of your on-line channels, average rate of new customer acquisition, etc.) then assessing disturbance to the overall UX might be as easy as comparing the before and after numbers of any of these indicators.

Also, if your website producers can move things around at will, you’ll need some new tools to understand the effects those changes have. A/B or multivariate testing of different combinations of blocks may help provide insight into any effects on the user experience.

We are definately going to set up some metrics to easily see where choices on the interface have impacted on user experience. Thanks for the list here as that will provide the bluepint for our sequence of measurements. We have also worked on other engagement metrics such as frequencey of visits, bounce rate, page impressions per user, time on site etc.

We are also working on A/B testing which with the new CMS, should enable the producers to conduct their own testing. As there are so many different sites this seems the only way to ensure a level of test and measurement. Our IA department numbers 1 – and the UX team are too stretched to offer anything other than consultation.

So this leads me to governance. The navigation (and revenue drivers such as subscription sign-ups) I think should be locked down. At present all elements on the page can be moved around, a WYSIWYG approach for the site editors. These elements are so key to user’s interactions that the thought of them moving rings the usability alarm bells.

I’m thinking an adaptation of your model, the layers you mention, needs to be constructed and outlined to all the stakeholders. So often our discipline seems to come across as the killjoy to the party when new technologies are bought and developed. It would be nice to somehow come up with a workable solution where our producers can create without feeling their hands are tied but our user’s needs are not compromised through changes in the interface.

Dan Brown’s take on this is interesting as he rightly states CMS is not linear and in fact the whole process will become more iterative – perhaps that is what we are leaning towards, iterative content management. With the testing and live metrics this will be even more true. I will keep you posted on future developments – but thankyou again for the series, it really has allowed me to start framing the problem.

Thanks again!
Rich

If you compare the components outlined in the Building Blocks with the stock portlet defined by JSR-168 (and the standard panes / tiles / widgets / whathaveyous in most of the vendor specific portal design kits) you’ll see that the blocks framework includes new, larger, and more sophisticated elements. This is largely and upward and outwwrd progression: The Building Blocks begin with Tiles as the smallest standardized element, and then offer larger elements that are based on Tiles, such as the Tile Group and View, that can interconnect in ways not offered by JSR-168, or platforms such as Sharepoint.

Note that because the Building Blocks are not tied to the universe of portals in any way, they serve well as a design framework for any modular environment composed of shared / syndicated / aggregated chunks of content and functionality. This support for fragmented content and services means the blocks are well suited to the public internet in the Web2.0 era, and other contexts besides. You can use the blocks to design everything from personal consoles, to web applications, to ubiquitous mobile devices. Consider the iPhone home screen – composed of lots of little apps that you can collect and group together – and the configurable ‘Spaces’ offered by the Apple OSX desktop. Overall, think of the building blocks as a modular design framework that supports synthesis of small set of standardized elements into larger and more meaningful constructs, not an extension or enhancement for any particular portal standard.

Does that help?

I’m writing a case study now to finish the series here at B+A, which will show several examples of how the building blocks have been applied in the past. I’ve also several presentations that explain the Building Blocks; these are available at http://slideshare.net/moJoe.