Talk:Specification Filter control property
Please forgive me for sounding negative here, but the filtering in OOo Base is highly disturbing to me as it stands, and if we are not careful it will just get worse. Although, I certainly agree whole-heartedly with the stated premise of this spec-- the end user needs a much easier time of filtering-- this solution seems like it would just make an already confusing situation, even more confusing. In addition it would not address the the most critical shortcomings of filtering in OOo Base.
We don't need yet another way of filtering added to the system. We need the current ways to be cleaned up.
I am not going to go into detail here, I am going to find another venue to discuss this. However, this is not in my opinion the way to proceed. It will just add more clutter and confusion to the design and use of filters.
Please forgive me for attacking your efforts. I don't mean to be insulting, I just mean to be direct. Base simply can't handle another pass without a serious look at its usability. As near as I can tell, nobody really seems to care that anybody, save tinkering developers can use it. Perhaps a more positive way to frame this is that in the noise of the serious complexity of this system, focus on the critically important aspect of usability seems to have been lost. Base will go nowhere without it.
In my opinion, usability is *the* most critical thing to address. If Base is refined (filtering is *critical* to this) so that it addresses the following defined user, it will start to draw more serious attention. Here is the user and the usability they need:
1) a computer power user (not a developer).
2) The user is more interested in her data and the information she can extract from it than in the tool doing the extraction.
3) The user has limited coding skills if any. She doesn't do much beyond spreadsheet macros.
4) The user wants to quickly import her data, with as many field types as possible being correctly auto configured.
5) She wants to point and click her way through filtering using an easy to grasp system.
6) She wants direct, quick and dirty form filtering for fast simple filters.
7) She wants an advanced filtering dialog to build complex queries in a point-and-click manner.
8) There needs to be only one advanced dialog and it needs to work identically in all contexts.
9) This dialog needs to present the selection lists for fields and not their raw values.
10) It needs to provide point and click date ranges with date selections using point and click calendars and spin buttons.
11) Operators appropriate for the current field need to be presented in a point and click manner.
12) Parenthesise need to be point-and-clickable, perhaps as indents in a Filter-Navigator type interface. ANDs and ORs should be also, and they should be clearly understood.
13) Ideally, any field type supported by Analyze-SQL processing should be point and clickable, for for instance, the comparison operators should be this way, as well as perhaps BETWEEN.
14) Any WHERE clause structure acceptable to Analyze-SQL should cleanly and automatically populate this dialog.
15) It might even be useful to have filters be nameable and persistent.
Some of these things might be overkill, however, in general this scenario should be aimed for even if not completely obtained. Even if more esoteric filtering is left to a user-keyed SQL WHERE clause (essentially the current state of date filtering for instance), all common filtering, such as date filtering, should definitely be point-and-click.
All the structure to achieve these features already exists in the system, with much of it being rather robust even as it stands. The Form-filtering infrastructure is robust, but its usability is a mixed bag bordering on the dysfunctional. The existing system really just needs to be cleaned up and refactored, with an advanced dialog added.
This is my view, anyway.
