Peter Moelgaard's Blog

Introducing Adobe WorkflowLab

Posted in Adobe, Adobe WorkflowLab, Methodology, Process by Peter Andreas Molgaard on October 21, 2009

Having returned from this year’s monstrous MAX in Los Angeles (monstrous due to the vast amount of sessions and networking).
One of the major impressions is the focus all of Adobe seem to have had throughout the past year on working smarter – not harder. This has reflected itself into every product and every aspect of the “Adobe Lifestyle” effectively offering opportunities and challenges to all of us making a living and life off the Adobe ecosystem.

One very obvious results of this thinking and focus at Adobe is the ALPHA release of the Adobe WorkflowLab, created by Mr. Doug Winnie and his team of skilled designers and developers.

Adobe WorkflowLab Icon

The Workflow below is the workflow actually used to create WorkflowLab, its one of the many templates installed with the application itself… in all modesty a cool way of sharing this information with the community as well as a way of illustrating the willingness and ability to drink ones own cool-aid.

Adobe Workflow Behind WorkflowLab Screendumb

The screen below is the startup screen meeting the user after starting WorkflowLab, as you can see on the right side, it comes with a number of ready-made workflows which will allow people to get off on the right foot when starting a project type that they have not done before.

WorkflowLab Startup Screen

Adobe WorkflowLab is already available in a very early ALPHA release on Adobe Labs… Check it out…
http://labs.adobe.com/technologies/workflowlab/

UXBASIS released by Hello Group

Posted in HelloGroup, InteractionDesign, IxD, Process, UserExperience, UxD by Peter Andreas Molgaard on September 22, 2009

At Hello Group we have created a website explaining how and why we what we do when working with our clients… we have named it UXBASIS !

2009-09-22_1607

UXBASIS is way of combining the numerous tools available to us and forming a unified process that sits within a digital agency and it’s other important departments – creative, tech and client services. The beauty about the model is it is fully adaptive to any clients needs, can fit with tech’s agile process and incorporates creative and development at key stages in the creation process.

The model is based on the creative process of a four part cycle; plan, act, observe and refine. On top of that is Jesse James Garretts’ five layers model for web development. The added bonus is that it doesn’t need to be a website but it can be any interface. It is purely ux focused but acknowledges the necessary touch points of where we need to engage with other parts of the business.Of course it is not new in terms of tools but it is in terms of making this work in a digital agency. An important factor is that the UX team has this as a manifesto and we stick to it completely. By having an agreed approach we can engage others in a common language.

We are producing cards (and we know they are not a new idea, see IDEO and the IA summit cards) to help our client services team communicate our methods to customers. It gives them the language necessary and helps cost projects by seeing when to use them and what they are.

It helps the company become more efficient keeps the quality of our work high and ensures transparency with the client. These tools all are valid and are frequently used. There are many more but these we feel are at our core to produce the best results.

The website is here with each tool explained and a poster and cards have also been produced. UX BASIS gathers it all up and makes our process transparent and communicable. It provides anchorage along the way for the journeys our client projects take us on.

Check it out…
http://uxbasis.hellogroup.com/

Mapping Design and Develop Disciplines… Team Competencies

Posted in Arbitrary Thoughts, Methodology, Process by Peter Andreas Molgaard on July 6, 2009

In continuation of mapping my own competencies, I have taken the liberty of mapping a couple of my colleagues whom are obvious to compliment me…

Its an exercise intended to give it a shot at using the matrix as a team constellation practice. However, instead of using the circle diagram defined by Dough Winnie, I have used the Radarchart from the ILog Data Visualization package.

2009-07-06_2347

The data are easy to make, the results are easy to understand and since the results might be of some relevance I intend to continue mapping a couple of our existing teams and the hold them against a radar diagram representing the project characteristics, and then see if the project-team is wrongly configured…

If the configuration above had been taken from a real project, its likely we could have been able to state that all bases were covered, at least to some extend…

You can check the small applet out here… or by clicking on the picture above…
http://petermolgaard.com/projects/competencematrix/OurCompetencies.html

Mapping Design and Develop Disciplines… My Competencies

Posted in Adobe Creative Suite, Process by Peter Andreas Molgaard on July 6, 2009

In continuation of reading Doug Winnie’s pretty clever article about how to map design and development disciplines and into a simple competence matrix, I decided to do my own…

The basic idea is for the individual to be honest in order to identify areas of where to improve as well as identify areas which may be more likely of creating positive outcomes when focused upon.
The extension of this is to use it for team constellation planning and for matchmaking in competence development programs, this will allow project managers to validate team competencies against project characteristics in order to ensure that all bases are covered for any given project. The approach is simple and in comparison to more elaborate approaches, maybe to crude for some who are already doing competencies matrices, but for those of us who are not yet having a program of such kind in place, this is an easy beginning.

Getting started with mapping competencies are really simple.
You start with downloading the template in an editable PNG file format.

makeYourOwn

And then you can modify it to match your own competencies and then e.g. compare with the profile you wish to match.
When I did that for myself, it came to look like this.

mycompetencies

Comparing with where I wish to be, I can see that I perhaps need to play around with Photoshop for a weekend or two…

Anyways… check out the original article by Doug Winnie for download of resources and to read more about the approach…
http://www.adobe.dougwinnie.com/?p=111

FC / FB Workflow Optimizer… sources available

Posted in ActionScript 3.0, Adobe AIR, Adobe Flex, AdobeFlashCatalyst, Code, Mate Flex Framework, OpenSource, Process, Tools by Peter Andreas Molgaard on June 3, 2009

I have made the sources available for the Workflow Optimizer… its a crude implementation but it does the job.
It uses Flex, AIR, as3preferenceslib, as3corelib and the Mate Flex Framework.

Don’t hesitate to comment on the ideas or concepts.. but don’t comment the code: it’s not written with any other priority than functionality…

Check it out…
http://code.google.com/p/workflowoptimizer/

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

Posted in Best Practices, Process by Peter Andreas Molgaard on October 6, 2008

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.

Power Designer 15 : Now in Beta

Posted in Methodology, Process, Tools by Peter Andreas Molgaard on April 24, 2008

I’m a great fan of system modelling, and therefore I am a great fan of a good system modeling tool.
Among the best imho. is PowerDesigner from Sybase and now its out in its most recent and 15th edition which is out there available in the first public Beta.

Check it out:
http://www.sybase.com/detail?id=1056477

The Daily Motivator : 10 Ways for a Web Worker to Achieve Work-Life Balance

Posted in Independent Thinking, Methodology, Process by Peter Andreas Molgaard on September 27, 2007

Som en af de der hyppigt ligger i toppen af den ugentlige inddaterings-summering i det firma jeg er tilknyttet tager jeg mig den frihed at dele denne artikel med jer.

Det er helt almindelig viden, men da det efterhånden er påvist udover nogen tvivl at produktiviteten (for slet ikke at nævne livskvaliteten) sænkes såfremt man glemmer at udøve fysisk udfoldelse samt at have et ikke-arbejdsrelateret liv gør det vel ikke noget at minde os selv og hinanden om det en gang imellem.

http://webworkerdaily.com/2007/09/14/10-ways-for-a-web-worker-to-achieve-work-life-balance/

Indhold i en af vores standard RUP iterationer

Posted in Methodology, Process by Peter Andreas Molgaard on September 3, 2007

Nedenstående er det overordnede format for iterationer vi arbejder med på et RUP projekt.

1. Assessment og eventuel tilpasning af processen.
2. Vurdering af use cases fra foregående iteration om de skal videreimplementeres i denne implementation.
3. Planlægning af iteration.
4. Implementation af eventuelle kritiske rester fra foregående iteration.
5. Implementation af use cases for iteration.
6. Etablering af baseline (executable, codebase og database ).
7. Review af iterationens resultater.
8. Opdatering af prioriteter samt krav baseret på resultatet af review.

Vi arbejder fortrinsvist med iterationer af 2 ugers varighed og vi oplever at ovenstående giver en god sammenhæng i en iteration og 2 ugers iterationerne giver en gunstig rytme på vores projekter.

Strategi for Test

Posted in Methodology, Process, Test by Peter Andreas Molgaard on August 31, 2007

Jeg kunne godt ønske mig (og jeg kunne faktisk også forestille mig at det kunne være formålstjenligt) at få nogle faste rutiner lagt ind i den løbende test-disciplin…
Det kunne måske være noget i stil med:

1. Funktions test (Med udgangspunkt i de funktionelle krav testes systemet fra brugerens perspektiv).
2. Sikkerheds test (test af systemet udfra de konkret definerede krav til sikkerhed for det enkelte system såfremt der er specielle hensyn og så selvfølgelig de helt almindelige krav der er til den givne applikationstype (For en generel webapplication: SQL-Injection, URL-modification, osv)).
3. Load test (der bekræfter at systemet understøtter de lovede load).

Tilbage ville så være følgende test, der i så fald kunne afvikles som en del af den afsluttende transition:

1. Chrash-Recovery-Continue test (Test af hvilken load-belastning der bringer systemet i knæ, hvilken tilstand systemet er i når crashet er sket samt om systemet kommer til sig selv igen og hvis ikke, hvilke handlinger der kræves for at bringe systemet tilbage i drift).

Afslutningvist ville kunden derefter forestå afvikling af en accept-test, som egentlig bare ville indeholde samtlige ovenstående test. Denne accepttest ville derfor være en ren formssag da de allerede var blevet afviklet under det forudgående udviklingsforløb.

Afslutningsvist for denne email vil jeg lige dele nogle af mine premisser for de ovenstående tanker:
• En test-strategi (uanset sin udformning og indhold) er et must-have for ethvert projekt !
• Samtlige test-former kan med den forhåndværende tool-support automatiseres (ja, sågar funktionstest bliver efterhånden med stor fordel automatiseret).
• Der er en absolut og direkte sammenhæng mellem kvaliteten af test og kundens tilfredshed. Denne sammenhæng korresponderes af kvaliteten af systemet (systemets levedygtighed, systemets vedligeholdelses-dygtighed, osv).
• Test betragftes som en overvejende regressiv aktivtet og derfor ikke-kreativt hvilket er med til at gøre det til en uattraktiv disciplin blandt de fleste mennesker. Dette er ikke sandt, testing kan sagtens gøres kreativt.
• Test giver frihed til kreativitet da man ikke er nødt til at basere sine beslutninger på antagelser (antagelser har det med at være forkerte).
• Der er meget få mennesker der synes det er interessant at teste, men at de trods alt findes, Denne type udvikler/projektmand er uundværlig og personer vi skal lede konkret efter i forbindelse med optagelse af nye medarbejdere, eller alternativt selv skabe i egne rækker ved feks. at automatisere test-aktiviteterne og derved gøre det mere attraktivt at give test-discplinen noget opmærksomhed.
• Test af et system er det eneste eksisterende synonym for at et system beviseligt virker. Da den videnskabelige metode i sin grundform er baseret på (lettere simplificeret og omskrevet til formålet): ide –> eksperimentering –> vurdering –> konklusion betyder det at vi uden test arbejder i modstrid med den videnskabelige metodes grundtese og derfor i modstrid med stamfaderen til alle best practice’s og alle moderne processer samt metoder… imho. ikke en særlig god ide :-)

This post was published to The Cynical Corner at 11:27:19 31-08-2007