Comments on Introduction to the Building Blocks

Joe Lamantia — Thu, 11 Oct 2007 16:52:01 GMT

Anyone curious about Jumpchart should drop me a line to get 3 free months of the service – it’s about to go from beta to subscription.

Joe Lamantia — Sun, 30 Sep 2007 19:03:46 GMT

@Parth: Glad you enjoyed the articles, and thanks for the primers on OOP.

Can you talk a bit more about the terminology parallels?

The blocks were created and used to solve real life problems so have been used in many design efforts over the past few years. Because the majority of this work was for enterprise portals of one kind or another, most examples are not publicly accessible. However, with very few exceptions, all of the examples used in the articles themselves come from real life.

As you’ve noted, conflicts in framing are one of the long-standing challenges for portal efforts; the blind men and the elephant is a good parable. I’ve had good results addressing the confusion by talking about three distinct but overlapping views: technology, business, and user. (See this posting for more background: http://www.joelamantia.com/blog/archives/executive_dashbo….

Parth Upadhye — Fri, 28 Sep 2007 19:14:05 GMT

Your tile-based thinking has many parallels in the component-driven software architecture world. I am a strong proponent of that and enjoyed reading your articles/thoughts. Also your terminology very close echoes those in content aggregators – Yahoo/IBM Pipes and connectors – and authoring IDEs – Container in Flex. Have you applied your model(s) to any real life examples yet?
Here are a couple of inks that do fair justice in explaining OOP for those not familiar with this software engineering approach: http://www.toa.com/pub/oobasics/oobasics.htm and http://homepages.north.londonmet.ac.uk/~chalkp/proj/ootut…

Reminds me of the story of the blind men and the elephant; each man touches a part of the elephant and declares what the object must be. Here the elephant is Portal and the participants are UX professionals, IA, SA (software architects).

Joe Lamantia — Wed, 26 Sep 2007 12:10:04 GMT

@Patrick: Jumpchart is definitely a good candidate for the building blocks. Check with Joe M on his plans for JC in the future.

@Joe: Thanks for the invite. And good luck with your product as it continues to evolve!

@Jeff: You’ve hit the nail on the head. This is “a conceptual model, an extensible and flexible structural framework”. And as some of the subsequent comments indicate, it is meant to be independent of vendors / tools.

Going forward, what should the packaged toolkit include?

@Floris: Great to hear that the blocks have made things clearer in your existing design, will help you communicate with other stakeholders, and that they’re working well with Axure (since it’s a major tool). I hope part 3 is even better for your needs!

Floris Nijdam — Thu, 16 Aug 2007 14:47:43 GMT

Excellent article.
At first it all seemed rather logical and not that new. However, after a while it really cleared my viewpoint on the matter.

I use Axure as a tool and noticed that the parts of the theory translates really well to the tool. I took the stacking hierarchy (figure 10) and translated the green bits directly into masters and the yellow bits into the site map structure.
(So I made Masters folders “_views” containing “_tile groups” containing “_Tiles” and split up/grouped some elements in order to correctly fit in the right folder. My sitemap actually fitted the other stacking levels already.)

Organizing and breaking down all my elements into these layers and thus becoming aware of their “true stacking identity” did not really change my design. However it did help me to get a grip on the vast amount of different elements in use. This will not only allow me to communicate more precisely with developers and designers, but also makes adjustments in Axure really easy. (For those that don’t know Axure: Masters link objects into other objects in your design. Change one and change them all. It is the ‘inheritance’ principle all the way)

I’m curious about part three and see if it will help easy my job like this article did :)

joe m — Tue, 14 Aug 2007 10:30:48 GMT

Patrick (commenter),
Before Jumpchart gets your hopes up, I have to admit I’m a bit confused by the article as it seems are some of the other commenters, so I’ll only respond to how Jumpchart might fit in.

* Jumpchart is system agnostic * Jumpchart does not currently allow for templates * Jumpchart most likely approaches IA, and organization from a much more simplistic approach than it seems like the author is echoing.

Joe (Author)
I would really welcome your input on Jumpchart. It’s obvious that you approach the organization of websites from a different angle than I’m familiar with. We have a very simple concept of organization. I’ll admit that we think of organization as a very modular process, so maybe we’re not too far off…

If you have the time, please contact me @ joe at jumpchart.com, and I’ll get you an invite for beta access to Jumpchart. Maybe we can see how/if Jumpchart fits in with your ideas…

Jeff Seager — Thu, 09 Aug 2007 13:53:37 GMT

Nice work, Joe. I think some people are desperate to see this as a literal toolkit, when in fact it goes far beyond that. What you’ve done here (and very well) establishes a way of thinking about information architecture that transcends all tools, but could integrate well with any tools. It’s a conceptual model, an extensible and flexible structural framework that would be useful in any programming environment.
In the end, our aim is always to create order out of chaos. This conceptual framework you suggest is very helpful for that.

Patrick Stapleton — Thu, 09 Aug 2007 11:57:31 GMT

It seems that the objects and the rules that you are describing here could be incorporated into a tool to make the process of designing/building web applications. Did you take a look at that Jumpchart link yet? (http://www.jumpchart.com/?code=D932A99) I would imagine if they integrated the toolkit you described many of us would be subscribers :)

Joe Lamantia — Sat, 04 Aug 2007 18:25:05 GMT

@Dave: Thanks for mentioning OO design: you’ve identified the source of some of the most essential ideas that run throughout the Building Blocks – a discussion we had to set aside in order to focus on sharing the toolkit itself. As someone with experience as a software developer, thinking this way no doubt comes naturally to you. We’re privileged to be able to borrow it, and hopefully realize some common good in the process.

Are there any good primers on OO precepts that you’d recommend to those of us with backgrounds in user experience and IA / design?

Looking ahead, it’s something clearly we need more of here in IA/UX land. In fact, I’d wager our future depends on finding a way to incorporate this kind of thinking into our tools, methods, and frame of reference. But that’s also a discussion for another time and place.

Meanwhile, I hope you find something in your travels here in IA/UX land that is worth bringing home with you to the realm of software development!

Dave Swersky — Fri, 03 Aug 2007 16:03:32 GMT

I’ve just finished this second article in the series and I’ve learned a lot, thank you! I’m a software developer by trade, and in the process of designing a web-based application I’ve developed a necessary interest in IA/UX. Many of the new concepts you’ve tied together here have analogs in the object-oriented design world, particularly Inheritance. Some of them are implemented, to varying degrees, in products like PHPNuke and DotNetNuke.

Joe Lamantia — Fri, 07 Jan 2011 19:39:13 GMT

@Andrew: Checking out the first article in the series should help set context, especially as some time has passed since the series started, in December ‘06. What you’re reading in this article is indeed a set of principles and assembly rules. Defining the blocks themselves is the next piece in the series (working it’s way through editing now). Assuming a downloadable toolkit is on the way with the upcoming installments, what should the package include?

The Building Blocks are a component based design system; one that attempts to address the specific user experience problems common to tile-based environments. AFAIK, this is the first such component based system to be released to public domain. It is by no means perfect, but the fact that is component based and internally consistent make it an improvement on design approaches that are completely ad hoc and unstructured. See part one of the series for more on the problems, and also Usability Weaknesses Inherent In Portals and Forthcoming Boxes and Arrows Series on Portal Building Blocks.

You said “I’m not clear how it’s really much more than ““build using reusable parts, ideally square ones that can be arranged in various ways.”” This is the flat portlet approach in a nutshell, and exactly what the building blocks try to get beyond. The design principles described here were chosen based on experience with how dashboards and portals tend to evolve over the long-term, and also to support a specific vision for shareable assets discussed in part 1 of the series. With a different vision in mind, and a different context of use (say, content management) the design principles driving the system would be different, as would the resulting framework, and its components.

It is very possible that another component based design system for portals would do a better job of solving the same problems. If – or when – such a system exists, I encourage its release for the benefit of the community. Until then, perhaps the community can use the building blocks as a starting point, and refine and enhance them to be more effective as a framework for solving these problems.

Note: future illustrations will contain rectangles as well as squares…

Andrew Otwell — Wed, 25 Jul 2007 12:56:14 GMT

I am confused by this article. You say “the building block system is a packaged toolkit”. Ok, where can I go download it? I’m not sure what you’re specifically talking about here. is it a set of files, or a set of design principles? I don’t think that a set of design principles really is a “packaged toolkit.”

As far as design principles go, this is all very well-described, but I’m not clear how it’s really much more than “build using reusable parts, ideally square ones that can be arranged in various ways.” i don’t understand how this *particular* system “can effectively support growth in content, functionality, and users over time” more than other component-based design approaches.

If I’m misunderstanding something fundamental, I apologize.

Joe Lamantia — Tue, 24 Jul 2007 18:34:38 GMT

Most of the building blocks related vocabulary you’ll see throughout the series – like Container and Connector – is ‘original’. Either it’s describing something familiar used in a new way, or it’s a new concept. If one of these terms isn’t clear, let me know, and I’ll try to clarify.

As for the bigger UX vocabulary, the IA Wiki is a good place to check. The IAI website also offers some terminology definitions. Foundational reading like the Polar Bear books, Garrett’s Elements of User Experience, Shedroff’s Experience Design, etc. are good resources.

Kris Gosser — Tue, 24 Jul 2007 13:43:10 GMT

Great article.

One quick question: What is a good recommendation for a book that goes through a lot of the underlying vocabulary used in this article (and most of the UX world)? I’m thinking about one that covers concepts like containers, connectors, etc.

Any recommendation of the best book out there would be great!