IDempiere/FullMeeting20120530

⇐ Table of Contents | Full Meeting Minutes | Full Meeting 2012-05-30

CarlosRuiz: Good day
a42niem: hi Carlos
Nicolas_: Hi everybody
tbayen: Daarestiet alltogether!
tbayen: If there is nothing on the agenda I want to talk about the right UI for IDEMPIERE-270
CarlosRuiz: agree
tbayen: I had an idea for a third kind of query. If we can activate multiselect on the table a user could select more than one record by hand.
tbayen: What is the right UI if you print a report to select between "single record" and "all not-filtered records" (and perhaps "manual selected records")???
tbayen: CarlosRuiz, you are right, my idea to use the SHIFT key while pressing the report button does not work in zk.
tbayen: (I have not tried it...)
CarlosRuiz: we have three buttons on swing and two buttons in zk
CarlosRuiz: "Report" button (for print formats) and "Print" button for documents (and in swing we have somewhat a duplicated functionality "Print Preview""
CarlosRuiz: Print -> is configured via the process related to the tab - so we can just have one configured - or can we have more than one?
tbayen: That is what I think. But you are much more experienced
CarlosRuiz: and "Report" button connect to the print formats defined - and show a list to chose if there are several
CarlosRuiz: I'm wondering if we simply have two buttons "Report Single" and "Report Multi"
tbayen: If the print button is for printing a document form and some people use the report button to print various document forms via the popup list there is something wrong with the UI.
Nicolas_: i would say that Print (defined in tab) is for 'nice' print formats (invoices, ...) whereas Report is used for reporting (standard print formats) ; i don't see a distinction between Single or Multi
CarlosRuiz: yes - and Print uses a different view per document
CarlosRuiz: Report Single - is the actual behavior you execute a print format showing just the actual record
CarlosRuiz: Report Multi - would be a new button to execute a print format with all the selected records
a42niem: i think the title of idempiere-270 says what would be necessary: just inherit the current search setting when calling the report
tbayen: Nicolas_, you say that there is a rule that reports with the left button are not allowed to be nice? Hihi
Nicolas_: tbayen : i don't catch :-/
CarlosRuiz: just a draft proposal - such solution seems better now that we can hide buttons from the toolbar - so if people don't want to use a specific button it can be hidden
tbayen: If you have a new button "Report Single" the only difference to the "print" button would be the view. Why not integrate these two?
CarlosRuiz: Dirk - Thomas found use cases where reporting a single record can be useful - so it became something that must be optional
CarlosRuiz: and apparently there are not a rule of thumb to know which print format must be single or multi - it depends on the usage
CarlosRuiz: so, Thomas implemented the button to behave dual mode - click and shift-click
a42niem: ok, then it would be bad to first have to go via search, understood
CarlosRuiz: but that represent a problem in zk
tbayen: I is thinkable that someone want to print different kinds of document forms from one record. Up to now you can do this with the report button using the popup menu.
tbayen: The real solution would be to extend the print button so that you can print these forms with a "print popup menu".
Nicolas_: or a sub menu (like the one for Zoom or Request) ; user click on 'Report' and then could easily select Single or Report ; same behaviour for all buttons
hahmed: toolbars with popup menus are not a very common UI element among applications. And even in idempiere it would be only used in this single case
hahmed: Nicolas_ submenu is better in my opinion
tbayen: The print button has to combine all defined "single page" formats with the entry from the register and create a popup.
tbayen: Nicolas_, there is already a popup on the "report" button - if you defined more than one report for this table.
Nicolas_: for me it is not a pop up but a sub menu
tbayen: OK - we can call it submenu.
Nicolas_: so we agree this solution
CarlosRuiz: do you mean that pushing the report button will show a list of all the print formats twice?
tbayen: How do we differentate whether a report is single page or list?
CarlosRuiz: i.e. "List of Invoices (Single)" and "List of Invoices (Multi)" ?
tbayen: I mean one list at the report button and one list at the print button (including the one configured for the tab)
hahmed: how about maybe print Single or Multiple based on grid toggle status
CarlosRuiz: tbayen, print button is a different thing - intended for single page print formats based on views
CarlosRuiz: hahmed, sounds interesting idea
Nicolas_: That 's an interseting idea but I fear it will break people uses ; actually, when you click on report and more than one is defined, people choose ; why don't extend this and show 'Single ones...' and then 'Multi ones' in a sub menu of Report button ?
tbayen: hahmed, this is easy and understandable to the user. Why did I not have tihs ideo
tbayen: Nicolas_, you force people to use this menu everytime - even in the simplest cases. That will annoy users.
Nicolas_: true
tbayen: On the other hand you are right that we may break users habits when changing it. :-(
Nicolas_: it seems that there is not a perfect solution
tbayen: Time for a SysConfig?
hahmed: Well in Single view having Multiprint option does not make sense, printing what the user can't see will be more confusing
tbayen: ...none of our solutions is good for users with old habits. :-(
tbayen: hahmed, right
Nicolas_: SysConfig and let user choos what he prefers in his profile ?
CarlosRuiz: one thing is habit and another is backward compatibility
CarlosRuiz: I don't mind too much if the change of habits is to improve usability
CarlosRuiz: and this case seems like it is
tbayen: CarlosRuiz, can you explain why we can not use the print button. I can not see the difference from user's view.
CarlosRuiz: use the print button for? singles?
tbayen: yes
CarlosRuiz: well - if you are on "Invoice (Customer)" window the list of print formats are those defined for C_Invoice table
CarlosRuiz: for the report button
CarlosRuiz: but the print format used for document is defined at several levels (bp, doctype, form) - and when the invoice is shown to you you can chose the print formats related to the C_InvoiceHeader_V view
tbayen: So the print button has some special logic to choose the right format. But why not use this "special" report and other single page formats to create a submenu. From a user's view it is all about "print me a page out of this record".
hahmed: tbayen, because the special logic is hardcoded in code and not easy to retrive it at runtime. (which is something we should fix eventually)
tbayen: I would do the following:
CarlosRuiz: indeed that is a wished improvement and it can represent a problem
CarlosRuiz: to allow user to select a document form - that's not possible actually for jasper formats
tbayen: If user presses button I look if there are single page reports. If yes, I create a submenu with them. First entry will be "standard" (after that one entry per report). If user presses standard I can do whatever the rpint button did before. - ...Am I wrong?
CarlosRuiz: although your improvement here solves the problem for multiple jasper reports invoice formats
CarlosRuiz: in this case I think the print button is correct and we better don't touch it - it's a way to print straight the predefined format for a document
CarlosRuiz: maybe you don't want users printing the wrong format for a different customer
tbayen: OK - I contradicted three times and you are not convinced. I give up and will not touch it. :-)
tbayen: I would like to summarize: We use one report button. In form view it prints a single record. In list view it depends on a SysConfig: Either it prints the filtered list or it opens a submenu (or doubles the entries in a already present submenu).
hahmed: I agree with Carlos that print button should remain as is for lets call them Forms printing (invoices, shipments, etc) while report button should be modified as required
hahmed: tbayen sounds good to me
CarlosRuiz: tbayen, I think if there are several print formats it shows the list
CarlosRuiz: as it is today
CarlosRuiz: what would change is the query passed to the report - in grid or single mode
CarlosRuiz: for jasper reports I guess you need to pass also the actual mode "grid/single" and you decide in your jasper what to do
tbayen: Nicolas_ mentioned to show a double length list in grid mode. There may be users that used this for something?!? I would configure this with SysConfig.
hahmed: Carlos, even that can be avoided as within jasper we can check the number of records returns using a master query and run the single/multi subreport
hahmed: Well gtg everyone. See you next week. Bye
CarlosRuiz: thanks hahmed - I'm asking Heng Sin opinion ....
tbayen: Bye, thanks for your ideas
CarlosRuiz: tbayen, the two buttons idea sounds clearer for user and for everybody
CarlosRuiz: and we have now the ability to hide/show buttons per system/window/role
tbayen: Is it good to create a new button and in the same second think about hiding it?
CarlosRuiz: I mean
CarlosRuiz: maybe you are interested to allow print multiple for some windows - but not for others - or viceversa
tbayen: Yes - if we can see which formats are predefined we can hide the single button in most cases.
CarlosRuiz: let's do it with two buttons - seems like the programming is easier and clearer also
CarlosRuiz: just that we need to add a new icon
tbayen: You better do not pay me to be an artist... :-(
CarlosRuiz: I guess we can take the report icon and add a little 1 in lower right corner - to represent single
Nicolas_: CarlosRuiz, i've made a commit on my fork for idempiere-255 (translation of items in VSortTab) ; added Name on PrintFormatItem_Trl and modify SynchronizeTerminology process ; it seems ok to me ; if you have time, can you please review ? i gtg in the next few minutes
CarlosRuiz: thanks Nicolas_ - I'll try to review it today