Search Views Guidelines
0 likes447 views
The document discusses search views in OpenERP. Search views allow users to search across relevant documents from different states or created by different users in a single view. The key components of search views are sorting buttons, main filter fields, extended filters, and group by options. Guidelines are provided for layout, icons, terminology, and ordering of these different components to optimize searches within a given business context.
Search Views Guidelines
- 1. 3.2 Search view 3.2.1 Introduction 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 in OpenERP allow the responsible user to search in only one view. Indeed, a Sales Responsible user, can see, in the same view, his created documents (sale orders) and, if he is allowed, the one created by his colleagues. So, in Sales Order menuitem, he can see all quotations, current sales and sales to invoice. No need to have ten different menus to separate his sale orders and other sales or different states of sales. Note : 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 used terminology 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 sort different states. Instead of using a state label “Draft”, we use a label more explicit for the sales context which is “Quotations”. 3.2.2 Components of search view Many options are given to users to optimize his searches. Buttons are used to sort quickly groups of important documents. Usually, a button is chosen following the importance of the document's type. We can take a look at an example, in sale order, it is important that the user can quickly see only the quotations that he needs. In all search views there are also some selected search fields. These fields are usually chosen regarding the importance of the object (related to column of list view). An example of this would be, in sale order search view, the salesman should be able to see current sales regarding only one customer. Some buttons allow users to group by elements, for example, salesman can group by customer and see, for each customer, all the sale orders they have made.
- 2. Finally, OpenERP allows users to search following most of the elements we can find in form view. If users want see all leads that come from one state in the United-States, they can add a filter easily and then save it as a preference, this is especially useful if they have to use it Often. Note : 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.
- 3. 3.2.3 Guide lines 3.2.3.1 Layout Sorting 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. 3.2.3.2 Icons Most of the icons are laid in search view. All of the buttons have to have an icon relevant to the function. OpenERP uses a range of predefined icons. Here are the most frequent icons (all icons are in annexe) : • When buttons refer to a Human Resources • When buttons refer to a date • When buttons refer to a product • When buttons refer to states ◦ Draft ◦ Open ◦ Pending Some icons are adapted. As we can see here, the “Today” button, we have placed the date icon and adapted it : 3.2.3.3 Terminology Like 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 a same way, the “user_id” field in sales is named “Salesman” and in project management, he is named “Project Manager”. 3.2.3.4 Guide Lines in details • Sort Buttons ◦ These kinds of buttons are on the top left of the screen. ◦ Sorting buttons are grouped by context (more often States and Dates). ◦ Inside a same group, button behavior is exclusive.
- 4. ◦ 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. Exception : in statistic reports search views, sort buttons related to dates are first on the left. Because, user date is important, statistics is often compute on a given time. A sale manager want see statistics of the month or of the year. ◦ If there is a current button, it is generally selected by default. This button sorts all draft and open documents. This is usually selected by default to avoid to see canceled and closed documents • Main Filter Options ◦ Default search fields might reflect the available columns in the list view. In other words, each field must have a related column in list view and is placed in same order than the column ◦ Fields must be free ◦ 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 sorts all documents of the current user and is named “My..” • this sorts 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.). • Group by ◦ like buttons, “group by” are organized in context. ◦ The first group is related to human resources, the second group is related to the state of the document. The third group is related to a place, and finally the last group is related to dates. ◦ A separator is defined between each group. For example : Salesman Partner | Stage State | Shop Company | Day Month Year ◦ Use appropriate icons as defined in the annexe ◦ in all search views, except for report's search view, groups by must be folded. The goal is to have simple view by default. • Extended Filters ◦ there are extended filters only in extended interface because it complicates the views. In simplify interface, user can use optional filters. ◦ by default, extended filters are folded ◦ Generally in extended filters, user can find important fields, but it is possible that no column is linked to the field. ◦ extended filters also give you the possibility to add columns that users might need.
- 5. With this button, user can add a column “Country” in the list view