Introduction

This post describes the best practices and polices to apply in Openbravo Forge to develop and organize an extension. These are a simplified version of the same guidelines that we use to develop Openbravo ERP core project plus some specific guidelines for the Openbravo Forge usage.

Let's start by defining some key concepts:

• Module: provides an atomic functionality. Examples of modules are reports, connectors, functional extensions, etc.
• Pack: group all the modules necessary to enable Openbravo ERP for a mean. For example, a vertical pack that collects all the modules required to enable Openbravo ERP for a specific industry.
• Template: a configuration file plus a collection of packs and modules
  

Documentation

Before starting any development, we recommend to create a set of documentation that will guide the development and will help users in the future to understand what the module achieves.

We recommend to have the following documentation:

• A Main Page that serves as an entry point to the projects' documentation and describes its objective and links to the related documentation.
• A Functional Specification that describes the functional requirements, use cases and other documentation that describe the needs that the module is willing to cover.
• A Technical Documentation that covers all the technical aspects to be taken into consideration when developing the module (such as database structure, etc).
  

You can take a reference the Human Capital Module to better understand how to organize this documentation.

Source Control System

Developers can use the source control system of their choice. Openbravo Forge provides Subversion as source control system. The instructions given in this section apply only to Subversion, including the recommended repository structure for Openbravo modules. You can leverage on your source control system specific features for branching and tagging.

The following is a list of common terminology used when working with Subversion:

Subversion client. Software run by a user to access a Subversion server also called Subversion repository.

• Subversion repository. The Subversion server stores a copy of the files of the project. The server retains both the most recent version and every historical version (past changes). * Trunk. Development with Subversion progresses similar to a tree. The main development occurs against the trunk.
• Branch. A split of development off of the trunk or another branch. Branches allow developments to diverge either permanently or temporarily.
• Tag. A tag or label refers to an important snapshot in time, consistent across many files. These files at that point may all be tagged with a user-friendly, meaningful name or revision number.
  

Recommended Repository Structure for Openbravo Modules

Openbravo recommends following structure when organizing the source code of your module:

project_name
* tags
* trunk
* branches

When developing a module, the main development activity occurs in the main development trunk.

All developers commit the changes against this branch. When a version is reach, a tag should be done.

If you want to work with a stable version you usually download the tagged version (a released version) and if you want to follow the development you download trunk.

We recommended the Version Control with Subversion free on-line book.

Registering Modules

As a prerequisite to publish modules into the Central Repository, you have to first register them.

This a list of recommendations when registering modules within the Central Repository from Openbravo ERP:

Use the field help to give precise instructions on how to use the module once is installed. For example, the required steps to access it from Openbravo ERP menu.

• Do not leave the URL field in blank, provide the project's web where users can find more information about your product.
• Do not leave the author's field in blank. It should be clear to the user who the author is.
• Package name. Use the standard package name naming conventions from Java, for example com.yourcompany.project. The package name org.openbravo is reserved for Openbravo as a company.
• If you are registering a module, use the same Single Sign-on username to register and then to associate it.
• Do not use the name of the client in the code or in the module definition
• It is fine to develop in other languages than English but the language of the module must be set accordingly
• If the module has been tested only in one database (Oracle or PostgreSQL), you might want to add that as a note in the module description ("This module should be data base independent; however it has been tested only on Oracle | PostgreSQL").
  

Creating Packs
Packs
When creating a pack project in Openbravo Forge, we recommend to enable the following services in Openbravo Forge:

• Module: to publish the pack in the central repository
• Forums: to discuss issues for the functionality that the pack targets
• Wiki: to document the configuration and link to the rest of the resources
  

We suggest to discard the usage of the rest of the services that the Forge provides.

Additionally, we recommend:

• Since a pack groups modules, they should not contain code, and as result, they should not require a source control system.
• We recommend to report issues, using the bug tracking system, to each particular module instead of reporting to a pack.
• We only recommend to publish files in the download area during the development cycle, you post your obx file in progress in the download area for early adopters to download and evaluate. We do not recommend to publish the files in the download service once they are released since you can already download files published in the central repository.
• When registering the project, assign it to the Openbravo ERP -> Packs category.
  

Module

When creating a module in Openbravo Forge, we recommend to enable the following services:

• Module: to publish the module in the central repository
• Code: to develop the code of the module and be able to work in a collaborative manner with other developers
• Bug Tracking: to allow users to report issues or functionality enhancements
• Wiki: to document the configuration and link to the rest of the resources
  

For modules, we suggest to discard the usage of the rest of the services that the Forge provides.

Additionally, we recommend:

• We only recommend to publish files in the download area during the development cycle, you post your obx file in progress in the download area for early adopters to download and evaluate. We do not recommend to publish the files in the download service once they are released since you can already download files published in the central repository.
• When registering the project, assign it to the Openbravo ERP -> Modules category.
  

Template

A template is a configuration file plus a collection of packs and modules. We recommend to enable the following services in Openbravo Forge:

• Module: to publish the template in the central repository
• Code: to develop the configuration file
• Forums: to discuss about the template
• Bug Tracking: to track issues with the configuration file
• Wiki: to document the configuration and link to the rest of the resources
  

Additional Information

Openbravo ERP development guide that includes all the documentation on how to develop extensions

Some of you might be familiar with how the database is usually updated in Openbravo. We have an ant task (update.database) that reads the model described in XML files (located in src-db/database), compares it with the current model in the database, and makes the necessary changes in the database to update it.

This process is key for Openbravo, as it allows us to change both database object definition and application dictionary content without recreating the whole database, thus preserving client data. In Openbravo ERP 2.50, it’s even more important, because it’s also the mechanism we use to add or remove database objects defined in a module (such as new tables, or new columns added to existing tables) to an Openbravo instance.

This task works fine for most common users. However, some users, particularly those working with special production environments that are shared with other applications, have some restrictions on the usage of ant tasks. For this kind of situations, we have designed a slightly different way to upgrade the database, using SQL scripts that can be executed through an external utility, but that are automatically generated by Openbravo and its database management tool, dbsourcemanager.

This new way involves using our ant task update.database.script. This task is very similar to the normal update.database in that it compares a model described by XML files with a live database, but it behaves differently in that instead of upgrading the database, it generates a plain text file containing an SQL script. This script contains all the necessary statements to modify a database like the one the Openbravo instance currently has, to transform it so that it ends up being like the XML files.

This process will allow people that have an Openbravo development environment in which they are developing their customizations, and a production environment in which for some reason ant tasks cannot be executed, to move their developed customizations to their production environment in a reasonably easy way.

The new task (update.database.script) works in Openbravo ERP 2.40 MP3, and in Openbravo ERP 2.50 MP1. I hope somebody finds it useful.

Introduction

Quality Assurance is key for having successful software products. Openbravo projects follow an open development process that allows everybody to take part in any part of the development process. Let me describe how you can get involved in the Quality Assurance processes for Openbravo ERP.

Before getting started we recommend that you read the following documents to get familiar with the main Openbravo development concepts and processes:

• Development Process Management. Describes the Openbravo development process from a management perspective.
• Openbravo Releases. Describes Openbravo releases and versions.
  

Openbravo testing methodologies

At Openbravo the following testing methodologies are combined to assurance the product's quality:

• Test cases: These area a set of well defined steps, execution preconditions, and expected results to exercise a particular program scenario or to verify compliance with a specific requirement. For managing test cases TestLink is used.
• Automated testing at Openbravo to automate the testing of Openbravo ERP using test cases.
• Unit testing using pieces of code that verify that functionality of different Openbravo ERP components. Currently in early stage using JUnit.
  

How you can help

Testing early releases

In the Openbravo ERP Early Releases Discussion forum we announce new alpha and beta versions that people can help to test.

Things that you can do to help:

• Verify that bugs that this release addresses have been fixed.
• Executing test cases to make sure that the functionality works.
• Test the new functionality and make sure that works properly.
• Reporting new issue introduced in this release.
  

Reporting issues on any version

Have you found a bug? Please, report it to us using our bug database. Make sure that you carefully read our Bug Reporting Guidelines before submitting your bug report.

Contributing test cases

For every release of Openbravo, at Openbravo's TestLink you have the collection of cases that are executed to verify the compliance of requirements. These test cases focus on assurance the coverage of the major use cases but not all the cases.

You can contribute by providing new test cases that you think that are important for Openbravo to include as part of our test plan (collection of cases) for every release or also cases that you think are critical for a specific module, industry or market segment.

Reaching Openbravo QA team

• Early Releases Discussion forum
• IRC chat channels
• Openbravo's QA blog
  

Tools

• Openbravo Issues. Openbravo bug tracking & enhancements database.
• Openbravo Code. Contains all the Openbravo ERP source code controls.
• Automated build farm. Openbravo continuous integration system.
• Openbravo's TestLink. Openbravo case management tool.
• Continuous Integration for Openbravo ERP.
  

We have published the final version of the Openbravo Forge User Manual. The manual covers the basic usage of the Openbravo Forge and its aimed to help project administrators and users on their daily use of the Forge.

The manual contains an introduction to the Forge and the services that provides, a detailed explanation of how to register projects, how users can fine tune their settings and how to use the Forge to develop, communicate and publish projects. We recommend this manual to all users using the Forge and to people willing to learn more about its capabilities.

If you have any question regarding the Openbravo Forge, do not hesitate to ask it on the Openbravo Forge forum.

The Certification program is one of the new initiatives launched by Openbravo this summer. If you intend to implement or build enterprise applications with Openbravo products, then passing certification exams will help you broaden your knowledge base and prove that you are ready for the job. The certification program can act as a passport to launching your company into the Openbravo ecosystem and giving yourself professional status.

The introduction of certification allows you to capitalize on the time and energy you spent learning Openbravo ERP; either though training classes, self study or 'on the job' experience. Certification offers a win-win-win scenario for clients, partners and Openbravo alike:

• Assures customers of your knowledge and skill and credentials.
• Shows tangible evidence of your ability.
• Adds to your credibility in the Openbravo ecosystem.
• Allows Openbravo to set a brand standard and monitor the quality of our partners.

Certification exams are available to every individual in the Openbravo ecosystem. If you are looking to differentiate and distinguish yourself in the eyes of your customers the most objective way will be to get certified.

The two exams introduced this summer will be at the entry or 'Foundation' level. The exams will be a timed 80 minute test comprising of 50 multiple choice questions and with a 80% pass threshold. Openbravo will rollout the Functional Foundation exam in June and the Technical Foundation in August. The scope of the Functional Foundation Exam is the functional modules available 'out of the box' with Openbravo ERP: Procurement Management, Sales Management, Production Management, Warehouse Management, MRP, Project and Service Management and Financial Management. The questions will be a blend of practical 'know how' and theory. Many of the questions have been written by our Consulting team so they are based on 'real world' experience. If you attempt the exam but fail on the first attempt you automatically get a free retake. However, if you fail a second time you will need to enroll and start the process again. The cost for the foundation exam is 150 Euros.

Foundation implies a starting point; something to build on. It rewards you for your achievement, but says there is more to learn before your become a expert. Therefore, later in the 09 calendar year Openbravo will rollout two more exams set at a higher 'Graduate' level. The objective with these Graduate level exams will be for the examinee to demonstrate that they can configure or build real applications given a set of requirements. Graduate level exams will again be a test of functional or technical ability.

Openbravo also has plans for a third 'Master' layer of Certification with which we really hope to find the 'Top Guns' in the community!

Passing each certification exam is much more than proof of attendance or a piece of paper on the wall. It is a tangible, objective and incremental way to examine, prove and demonstrate if you have the skills required to implement and build production enterprise applications using Openbravo products. Certification will mark you out as an Openbravo Professional! In this sense it is serious business and will take work from you to reach the grade and standard required. Your reward will objective proof of your ability and status in the Openbravo ecosystem.

There are several excellent preparation options available. Ideally if you plan to take the Functional Foundation Exam we recommend you attend the Basic Functional Training class, either in the classroom or on line. Similarly attending the Basic Development Training will prepare you for the Technical Foundation Exam. Find below some helpfull resources to prepare the exams:

• Hands-on instructor-led training
• Online training
• Openbravo Wiki

To enroll for the Functional Foundation Certification Exam, please visit http://www.openbravo.com/services/certification/

If you have any questions please do not hesitate to contact us at training@openbravo.com

Eugeni Vives
VP of Global Partner Services

ERP is a domain that is associated with large amounts of data and complex processes. ERP software traditionally uses tables and forms to visualize the data and in many cases processes are not visualized at all. The reason for this is historically: Activities such as planning, purchasing, sales and financial management are mostly about numbers and the way these numbers are "visualized" has hardly changed in the last 100 years. This cash book still looks very similar to the one we use today. This does not make it any easier for people working with it, whether it be designers, developers, business partners or end users.

I believe that we can make things much easier by applying visualization in our every day activities and this does not only apply to building flashy user interfaces or creating sales forecast charts. Visualization can be used to gain insights that you would never have thought of before, it can be used to seduce customers, your boss, your peers and the opposite sex. It can be used to spur creativity, invoke discussion and generate alternatives. And the effort it takes is much lower than you´d think. Let me illustrate all this per activity and object type.

Ideas & Insights

So you have this great idea or insight, right? What are you going to do with it? Mostly, you need to get buy-in, so what do you do? Describe it in an email and hope people will understand it? We are surrounded by many smart people but most of them are busy and don´t want to use their brain cycles to understand what you want them to understand. By visualizing your idea or a problem you make it easier for your audience to grasp what you mean and because you made it less painful, they will reward you with their support (providing that the idea was good of course). Another happy side effect is that by visualizing your idea or problem, YOU will also understand it better. Those who are best in visualizing a problem, are most likely the ones to solve the problem.

Design & Development

From requirement to code is a long way and many things can go wrong. Traditionally business consultants distilled requirements, wrote use cases to capture what the system needs to do and the developer converted those in functional specifications outlining what technology architecture will be used. Nowadays most development companies also employ user experience designers who are in charge of designing the user interface. One of the most differentiating features of these people is that they tend to visualize ideas and concepts as early as possible in the design process. In fact, they start sketching the moment they enter a meeting room for the first project brief. This really helps the team to understand the (same) problem and to evaluate the different solutions before a line of code has been produced. The last months we shared all design work online with the community and solicited feedback in every step. This saves time & money, brings more and better ideas and results in better quality with lower risk. We should all be sketching more often.

Data

The source of all data is in tables in data bases or in spread sheets. This is not going to change anytime soon but the way to present the data is much more flexible. An image (or video) says more than a thousand words so just have a look at this tremendous presentation of Hans Rosling who makes boring statistics come alive. Try to put this in a spreadsheet and make people understand it! There is a great opportunity for us to use visualization in ERP systems when we start to include business intelligence (BI) functionality. This will help us to view the data from different angles and to gain better and earlier insights than with using traditional data views. It also lets us interact with the data. A great example of effective data visualization is the NY Times interactive chart for the 2008 Olympic medal count. One of our community members shared some great ideas for data visualization and manipulation for Openbravo ERP.

Processes

Things happen over time and most of the time the path via which things happen is not linear but depends on certain conditions. This can get quite hard to understand without visualization. I was very happy when the Openbravo team started to model the most common business processes. Now we understand on the most abstract level what task flows we need to support. Everything we design and develop should be supporting those. Process visualization can be used everywhere: From a simple HR process for doing your expense report to helping a potential customer understand how the sign-up and installation will work and when the payment takes place. When I moved to Spain I had to apply for a health card (tarjeta sanitaria) but I was unable to find any process description (not even in words) which eventually made me visit 6 different administrative offices (all with very Spanish opening times) all over the city. Half way I had no idea what form was supposed to do what so I ended up dropping the whole pile of documents on the next desk in the process explaining to the staff: "I just need a health card, take the paper you need and tell me what to do next!". It took me almost a full day.

Pretty Products & Presentation

One study at the UCLA indicated that up to 93 percent of communication effectiveness is determined by nonverbal cues. That was about direct communication between people but it isn't hard to imagine that similar figures apply to other channels. The power of good looks can be used to your advantage. People like to use beautiful products, it makes them feel happy and confident. Your customers are people too, they like to use a handsome ERP system and look at beautiful presentations, pretty invoices and cool looking sales charts. Among techies, aesthetics are normally not considered to be very important, it is all about features: The iPod was a "lame product" according to a post by a Slashdot community member because it did not have wireless and less space than a competing product. S(he) Obviously did not understand that good design & simplicity can beat feature count. There is nothing shallow about liking pretty stuff and you better make things look good if you want to impress.

This was part I. In part II I will give you some tools and methods to let you do the visualizing.

Since I joined Openbravo in April, I’ve been hearing a lot about “modularity” and what a significant enabler it is for the ecosystem. Paolo Juvara wrote an incredible blog post on this topic, detailing the technology and explaining the theoretical ecosystem dynamics that it supports. There is a lot of information in that post, and it raised a number of “food for thought” business questions for me that I’d like to get feedback on.

Before raising those questions, here is my shorthand on modularity’s “Big Idea”:

• Reusability + Autonomy + Exposure = Scalability (of the Ecosystem)

Let me explain. As a participant in a software development ecosystem (or you can use the word “community” if you like), I have 3 major business-oriented goals:

• Reusability: Let me leverage the work of others
• Autonomy: Let me create what I want and contribute it (so others can leverage)
• Exposure: Provide me a means of public recognition (so I can monetize my contributions in some ways)

When a software ecosystem is structured to effectively and efficiently meet these 3 business goals, then it is designed to be scalable, with no internal factors gating growth. Openbravo Modularity certainly provides for reusability, allowing formal packaging at 3 levels of granularity (module, pack, template). And its formal dependency support enables reuse across versions and different authors. Autonomy is also provided, as well as exposure (through publishing modules via the online Central Repository).

So all of the basic requirements are met. What’s not to like? J But of course the key business challenge with all new platforms and ecosystems is that their growth is governed by the “Network Effect”, in which large benefits to the participants don’t accrue until a “critical mass” is reached (in this case, a critical mass of software authors and users). So, until there are large numbers of consumers, it is difficult to attract large numbers of producers. Conversely, small numbers of producers discourage new consumers from joining.

The platform must deliver enough tangible value to attract increasing numbers of both producers and consumers over time. We at Openbravo are adding that tangible, practical value to our ERP platform on a continuous basis, and Modularity is a part of that. We are very excited to see where the ecosystem takes this!

With that backdrop, it’s time for my “food for thought” questions related to Openbravo Modularity.

Both commercial modules (pay first, then download) and community modules (free as in both beer and speech) will be supported in Openbravo's integrated Central Repository. Which will dominate? Stated another way, will most module authors act as ISVs (creating software that they enhance and maintain over time), or will most freely contribute their work to gain recognition for the purpose of selling custom services (effectively using their software as an advertisement)? Will the pattern change over time (as the number of consumers grows)? Will authors who started as custom services developers gain domain expertise in an area and evolve into an ISV focused on that vertical? Will authors start out charging for their modules, and then turn them over to the community after a certain period of time (when they have recouped their development cost via the sales)?

What about module size and granularity—will we see large numbers of small “drive-by contributions” (single reports, small integration to a 3^rd-party system, purpose-built inquiry screen, etc.), or a smaller number of complete industry templates? How will that pattern change as the ecosystem grows? Will end customers contribute modules, or only partners?

What will the partner channel look like over time? Will most partners continue to Develop, Sell, and Implement, or will we see increasing specialization over time (perhaps with most custom Development clustering in countries with favorable labor rates and quality developers?). Will some organizations focus on selling, subcontracting the implementation work to others? Will partners collaborate extensively, with partners on one side of the globe localizing modules created by others on the other side? (the Openbravo Forge will certainly enable that!)

Will “first move advantage” dominate, i.e. will being the first module for a certain area generally mean you will be number 1 two years from now? Will the presence of an existing module discourage other authors from competing, or will we see a lot of competition in high-volume niches?

What are the biggest challenges to Openbravo's 3rd-party ecosystem reaching critical mass? What can we do better?

Please feel free to provide public feedback / speculation here.

Continuous Integration (CI)

• Continuous integration servers constantly monitor source code repositories
• As soon as new changes/commits are detected, they initiate a new build cycle.
• Build cycle actually involves code compilation and, in addition, may involve various tests and code analysis.
• If the process encounters errors, it notify the build master

Openbravo leading professional web-based Open Source ERP! decided to use Continuous Integration, a software development practice to make its team integrate their work often. I explored on few CI tools like Cruise Control (CC), Buildbot and Hudson. I liked Hudson for reason likely

• Installation and Configuration (friendly web GUI with extensive on-the-fly error checks , in-line help.)
• Extensibility through plugin
• Permanent links (gives you clean readable URLs for most of its pages)

Hudson Architecture
Hudson a continuous integration tool, which schedules the job process as cron job,

• It is primarily a set of Java classes likely where Hudson is the root Object model, it has 'project class' and 'build class' and some 'interfaces' to perform some part of build like scm
• Hudson classes are bound to Staple (Stapler is a library that "staples" your application objects to URLs, making it easier to write web applications. The core idea of Stapler is to automatically assign URLs for your objects, creating an intuitive URL hierarchy.)
• To render a html pages hudson uses Jelly (is a tool for turning XML into executable code. So Jelly is a Java and XML based scripting and processing engine)
• It uses file system to store, data directories are stored in HUDSON_HOME as plain text like the console-output (few as java properties file format, Majority of them uses Xstream, eg : project configuration, or various records of the build)
• Hudson can be installed either by running the hudson.jar file(ex. java -jar hudson.jar) or just by deploying it in a servlet container.
  

How I deployed

I deployed Hudon tomcat on port 8080 and redirected to port 80 (default) using mod_jk and apache on a gentoo operating system

• deploy the war file in tomcat directory
• Add "-D JK" to /etc/conf.d/apache2, in the APACHE2_OPTS line.
• Add "JkMount /* ajp13", at the end, before to /etc/apache2/modules.d/88_mod_jk.conf

check Openbravo's Continuous Integration system here

Ease of use is more then user interface (re-) design; it is also making sure the processes implemented in the application match the user´s mental map and match the way companies do their business. For this reason we have been working on modeling the most common ERP business process flows. We would like to share the resulting diagrams with you in order to collect feedback and improve them. Each diagram documents an abstract business process, which should result in a business-process-specific discussion. It will also provide a natural place for people to discuss current issues about or suggest changes to the current Openbravo-specific implementation.

Another reason for describing the business process flows is to provide better user guidance through our documentation. Surveys told us that this is a key priority for our community and therefore for us.

Please provide feedback per diagram (thread) to validate the correctness and completeness of these flows. Also, let us know when you think that a crucial process is missing. The finalized flows will be used as input for the UX redesign.

In the last weeks mockups for the new GUI for OB ERP were tested on 12 users. Let me share the findings with you.

What was tested: three clickable mockups

Test methodology: participants were asked to execute a number of tasks, as described in the scenarios. They were asked to think out loud while doing so. All mouse movements were recorded, as well as the audio (participant talking). A web cam was used to record the user´s facial expression. The facilitator observed the participant, took notes and asked questions in case of hesitation, mistakes and other deviations from the pre-determined scenario path. Other than with the contextual inquiries (user observations) that were conducted in December 2008, I have decided not to post-process(annotations, etc.) the videos as the findings were extremely consistent across all sessions. The sessions were split in parts: 4 tests were done at first and findings were immediately processed into a modified design (biggest change was in the ribbon toolbar). The remaining 8 tests were done using both the initial design and the modified designs.

Findings: The most important findings are:

* Users have difficulty navigating the different master detail views from parents to childs, from grids to forms and back. There is definitely a learning curve but cognitive load seems to be high. I think part of it has to do with visual design but I´m concerned that this can only fix parts of the problem.

* Users have troubles finding menu items (buttons) in the ribbon toolbar. I noticed that the labels I initially used (such as "record") were not ideal, and changing them to more common labels (such as "edit") significantly improved the user´s performance. Still, it took most users a while to get used to the concept of "buttons hidden on tabs". Some users even thought the the form or grid below the toolbar was part of the tab. Here visual design and labeling play an important role but I have the feeling we should simplify, dumb it down. Plonking all buttons (icons) in one bar is perhaps the way to go. Users don´t seem to notice a difference between generic buttons and object specific process buttons but I still want to keep this clean separation, as in the earlier concepts.

* Forms work great. Users love the layout, the nifty sections and the color coding on field and section level for required fields.

* It was not always clear when records are saved and when not. Users did not seem to worry about it at first but seem to wonder what saving mechanisms are applied and demand clear feedback on the status. Auto saving is not always good: an implicit save action is requested for forms to avoid unfinished forms to be saved or even processed.

* Users double click rows in grids

* Users get confused about which tab contains what because of missing (id) labels on the tabs

* Three users had concrete examples of use cases where flicking through the headers while observing a related lines grid update is needed.

The detailed findings can be found here.

Now the next step is going back to the drawing board and solve the issues pointed out by our users. After that, another round of usability test might be necessary. As always, you are welcome to participate in all stages of the design process by posting on the UX Lab Forum.