Design Patterns : Presentation Model

One pattern I can see that is not as widely used as it deserves to be is the Presentation Model as it’s discussed by the legendary code-pattern-artist Martin Fowler.

Paul Williams have furthermore taken Martin Fowler’s description and refined it for the Flex framework where he points out how specifically to apply the pattern to a solution based on Flex.

Check that out here…

I am working on some similar Flex specific interpretations of general design patterns, and among others I will use Presentation Model as designed by Martin and refined by Paul… its truly great stuff you guys are enriching our community with… thank you.



”mate” flex framework

Lately is has become less and less important for the projects I am working on and planning to work on to maintain developer neutrality by attempting to target platform-agnosticism. This has allowed for me to look at the alternatives out there, the recent solutions have been based on the PureMVC framework invented and developed by legendary Cliff Hall.

It has many times been “painful” for me to refrain from taking advantage of some of the platform-specific stuff, so it’s with great pleasure that I have resumed my early fling with “mate” which is a framework that is born with Flex and fully embraces all the technology specific stuff we all think is so cool about Flex.

Mate is a tag-based, event-driven Flex framework. Flex applications are event-driven. Mate framework has been created to make it easy to handle the events your Flex application creates. Mate allows you to define who is handling those events, whether data needs to be retrieved from the server, or other events need to be triggered. In addition, Mate provides a mechanism for dependency injection to make it easy for the different parts of your application to get the data and objects they need.

Check it out..


User Experience Guidelines

Both Apple and Microsoft are offering user Experience Guidelines resources for developing applications targeting their respective platforms.

In addition to the non-product specific ones, such as the previously mentioned Yahoo Design Patterns, these are essential when designing User Experiences and can save both Client Application developers and Information Architects a lot of time both defining, but eventually also defending and explaining their ideas and decisions… as well as eventually making more successful user interfaces giving a more fluent and positive Human-Computer-Interaction altogether.

Apple Human Interface Guidelines

Microsoft Vista User Experience Guidelines


Yahoo Design Pattern Library

Yahoo has decided to share their design patterns with the developer community… it’s important to note that it’s not GRASP patterns, but patterns for establishing Information Architecture (IA) and designing User Experience (UX).

The patterns are to be found here

…and if you like what you see, Yahoo are even offering stencils for creating wireframes based on their patterns in formats such as Microsoft Office Visio and OmniGraffle as well as directly in PDF, PNG and SVG.


Introducing IANA

At the core of application development are protocols and standards… which without both we would all just be a bunch of hackers and cowboys.

I find myself browsing the IANA website often when I am defining an API – because as you will find out once you start using the IANA catalogue, there is a standard for everything and there is no need to break the standards if it can be avoided.

Some parts of the IANA catalogue are more useful than others… among the high-ranking sub-sites are the following…



…and among the more curious is the Operating-System-Names… which has not been updated for more than 6½ years…


Be the change you seek… document your code – even though others don’t

One of the core values I try to promote on my team is “be the change you seek”…. this also goes for programming and documentation. Most developers tend to complaint about code if it’s not thoroughly documented, however more often than not I see the same developers not documenting their own code if they are working on a codebase with little or no documentation. My recommendation is to be the change that you seek and start documenting your own code… soon other developers will follow and eventually the codebase will be documented… its truly that easy: you can make a difference !


Removing the noise… How to eliminate the unnecessary distractions from projects…

Distractions – let us count the ways. There’s nothing unique about the distractions we have at Hello — email, the lure of the always-on Internet, and too much personal chatter, just to name a few. What is different about our distractions is that we’ve stepped back to try and rid ourselves of the “noise” among us and around us, so we can stay focused and deliver great rich Internet applications on time and in budget.

You may not work on technical projects like I do and we do at Hello, but all projects are subject to the same kinds of distracting ills. During a recent process of improvement reflections, I have compiled a handful of quick ideas that will help any team increase its productivity.

With extensive experience in project management, and having seen distractions compound as the RIA technology around us becomes more sophisticated, we believe these ideas are essential for teams to stay focused, meet milestones efficiently, and do better work — three professional ethics that will ultimately lead to higher profits.

Identify a key person from each department to represent the team.

The point person’s job is to bring pertinent information forward from the team to the project manager. On our projects, a team may consist of designers, developers, information architects and engineers. Of course, they meet often on an ad-hoc basis, which is great. It’s the project manager’s job to stay in close communication with key people so pertinent information from informal gatherings is formally articulated to the entire team through meeting notes and status reports.

Manage side trips.

Our RIA projects can last anywhere from two to 12 months. On long projects, the road to completion may seem to wind sideways at times, which can be frustrating. It’s important to keep the team and the client focused on the fact that this is the nature of the work. If this were a river rafting trip, you have to “look long” while navigating each set of rapids as effectively as possible without any paddlers falling out of the boat.

Become the go-to person.

If you are a project manager, the more you know about the project, the less you need to interrupt your team members. It will behoove you to become a subject matter expert with a strong understanding of the project — the focal point on which your client relies. Answer as many question as possible yourself to minimize interruptions for the rest of your team.

Stop churn in its tracks.

When five or more emails are generated on the same topic, put an end to it in short order. Avoid the group response syndrome, in which team members are responding to each other’s responses. Table the churn promptly and flag the issue as an agenda item for the next status meeting. Resolve it and redirect the team forward.

Provide a focused, thoughtful agenda for team meetings.

When a project manager sets an agenda, it forces them to think through the issues. It also should dictate who really needs to attend the meeting. For instance, invite the designer who has been hands-on with a critical component, even if she is not a team lead. Select attendees based on topic and keep the discussion concise and focused on the agenda items.

Mark the difference between collaboration and conversation.

At Hello, we work very collaboratively, which is great. However, collaboration can rapidly disintegrate into conversation all too easily. The trick is to engage fully with the collaborative process without falling into random conversation. Decisions can’t be made conversationally; they can only be made collaboratively through informed communications.

Document the inputs and results of meetings.

The only way to ensure a clear understanding of decisions, action items, issues and accomplishments is to memorialize them in writing. We should use standard templates for the two kinds of meetings required on every one of our projects: weekly status reports and meeting notes. Neither of these templates is very sexy, but they will work. In our business, meeting notes are often quite technical, so we can include a synopsis in the weekly status report.