Translations by Victor Yu

All menus have to be suited to one business application. One user has to see all menus linked to his job. He has to be able to make his workflow in one menu only. This is the goal of all the applications. The user should be able to navigate through all his workflow from a single menu to make his work easier, faster and user friendly.

As previously mentioned, OpenERP is developing within a business framework and vision. When using OpenERP, users can find business applications, in these applications, they can surf on some of the business oriented views. In this search view they will also find that it facilitates the work and the search of the user.

search views are present in some of the types of views. There is a search part in calendar view, in list view and in statistic reports.

The terminology used to qualify each element of the search view are related to the application and also to the business context of use. For example, in sale order, there are buttons to filter different states. Instead of using a state label “Draft”, we use a label more explicit for the sales context which is “Quotations”.

In extended view, in some search views, there are extended filters. These are used to allow user filtering on important elements but are not specific to a list view. For example, in Leads, there is not the Lead's country in the Lead list view, but, it regularly happens that Salesman want to filter all Leads by a specific country. It also allows you to modify columns of the list view by adding one. This kind of field is only on the extended interface and not in all search views. Our goal is to simplify, so if it is not necessary, there are no extended filters. A user can always use a personal filter.

Configuration wizards are launched automatically on creation of a new database. You must develop configuration wizards per application to:

Help the user configure the system

For the point (1), fewer user-installed modules make it easier to understand the system. So, most features are proposed as extra in the configuration wizards.

For the point (2), where possible, it's better to provide a default configuration that works for most companies instead of developing a configuration wizard.

Don't forget that configuration wizards are to help users tailor the system to their requirements, not to ask complex questions for very specific configurations.

OpenERP allows users to configure their installation to their business's needs. When a user creates a database they can choose one or more applications. They will then see some configuration wizards to add modules related to the chosen application(s) and so, their needs. For example, if the user has chosen “Project” they will see a wizard to configure Project Management.

We usually try to define new business applications related to job positions in the enterprise. These are good examples of applications : Purchase, Sales, Accounting, Project, etc. Don't create business application by features. These are wrong examples of business applications : lunch orders management, expenses sheets, etc.

Each application must create an entry in the main base_setup wizard that shows all the possible business applications defined in quality certified modules only.

You can also create one configuration wizard dedicated to your business application. Example, when you install the project management, you get this wizard:

One user/role must be able to perform most of his tasks from one business application. He should not be forced to switch to another application to perform the tasks of the same role. Example, a salesman should see in his menu: Leads, Opportunities, Meetings, Sales Orders, Sales to Invoice, etc. He should not be forced to go to the accounting application to invoice the sales.

Some features should be accessible by all users, not depending on the application they usually works in. As an example, most of the users should have an access to: Partners, Agenda of Meetings, Products. In that case, you put the menu in the applications that needs these features more. (Example: the address book is in the sales, purchases and accounting application) And, these features must be set as shortcuts for every user in the system by default, at the creation of the user.

The groups defined by each module must be directly related to business application. So, if you have an application which is “Accounting”. All groups within this application must be like: “Accounting / Accountant”, “Accounting / Financial Manager”, etc.

Each business application must have one dashboard attached to his root menuitem. When a user enters in a business application, he should see the dashboard related to this application.

The first items of the main menu (application management) have to be the most useful documents of the application. There are 2 reasons for this:

users must have direct and easy access to his documents, usually, most important features which correspond to daily operations.

If the application contains the object “res.partner” it is always after the main menu. Because, it is important to have easy access to the suppliers in “purchase” or the customers in “sales”.

“Reporting” is always before “Configuration”. From the managers side, it is the last item.

If the application contains the object “res.product”, it is always before “Reporting” (from user side, it is the last item)

the invoice object; if there is one in the application, it must be before “Products)

All other menus are organized in a logical order. For example, in “Human Resources”, user have generally more often the need for “Time Tracking” than “Expenses”. So “Time Tracking” is placed before “Expenses”

To summarize menus have to look like :

Main application

(Address book)

(Billings)

(Product)

The used terminology must be short and explicit. Firstly, it must be short because in web client, main menus are organized on the top, in a horizontal bar. So it cannot take too much space. For instance, we don't use “Purchases Management” but “Purchases” to minimize the space taken in the menu.

Secondly, used terminology must be linked to the application and explicit to it. For example, res.partner object is named “Customer” in “sales” and “Supplier” in “Purchase”.

Filtering buttons and main filter fields must be the first elements on top of the view, and on the same line. Below this main filter option, you must place extended filters and group by one above the other. Each field group must be placed in a new line. Finally, the search bar must be below the view as displayed in the picture above.

As previously mentioned, the used terminology must be adapted to the application. An example of this would be, in sale order the search field “partner_id” is named “Customer” and in purchase application, the same search field is named “Supplier”. In the same way, the “user_id” field in sales is named “Salesman” and in project management, it is named “Project Manager”.

These kinds of buttons are on the top left of the screen.

Filtering buttons are grouped by context (more often States and Dates).

Inside a single group, button behavior is exclusive.

Each context is separated by a vertical separator.

The first group is always related to states (Current, Pending or Open).

Then there are other buttons in one or more groups, it depends on the context. These are specific to the current view. For instance, in sale orders, we have “to invoice”. Finally, if there are buttons related to the date such as, “This Month” or “Today”, it has to be last group on the right.

In statistic reports search views, filter buttons related to dates are first on the left. Because user date is important, statistics is often computed on a given time. A sales manager wants to see statistics of the month or of the year.

If there is a current button, it is generally selected by default. This button filters all draft and open documents. This is usually selected by default to avoid seeing cancelled and closed documents.

Default search fields might reflect the available columns in the list view. In other words, each field must have a related column in the list view and is placed in the same position as the column.

Near fields like “user_id” or “section_id”, following the current view context, we can find some buttons

near “user_id” field we can find the following buttons :

this filters all documents of the current user and is named “My..”

this filters all unassigned documents. This button is used in views where documents are self generated such as leads.

Near “section_id” we can find buttons generally used in views related to sale's applications. This button shows documents linked with current user's department(sales/marketing/HR,etc.).