Hi, I offered and would like to write a specification concerning Base. As I understand the procedures this would only make sense if I had an i-team, which I currently lack.
So please read on, as I need a member of dev, ux and qa. I hope, this is the proper approach to find these members. Anyway, I don't know any other way. Please excuse me if I did it wrong. In order to introduce the project I will write something about (1) What is the subject of the specification (2) What should be improved (3) What the specification should describe (4) What I think I can offer OOo Since the spec affects Base (dba), maybe answers to this mail should be addressed to d...@dba? (Ad 1) As far as I know, there is no issue, but only the description of a developer project in [1] [1] http://dba.openoffice.org/development/projects.html#new_filter (Ad 2) Currently Base has two filters: (a) The "filter dialog", used to filter rows of a table or query shown in the data source browser. It is also used to add a filter in the properties dialog of a form (at design time). (b) The filter navigator used to filter rows displayed in a table controll of a form (at runtime). Both of these filters are quite different with respect to capability and user interface. At least to me this was quite confusing at the beginning. The specification should have the following objectives: (A) Unify the user interface, i.e. describe a user interface for a new filter dialog that can (and should) replace both, the old filter dialog and the filter navigator. (B) Enhance the functionality of the filter so that it will also meet the requirements of power users. It should be possible to define filters with more complex filter conditions. (C) Provide a dialog that is easier to use. (D) Provide a dialog that is more intuitive to use. Well, (D) may turn out to be problematic, since I don't know any way about how to measure intuitiveness. (Ad 3) The specification should... (a) Describe the logical structure of the filter without any regard to the user interface. This will precisely describe the functionality of the filter. This should support implementation and testing. (b) Describe the user dialog, i.e. the interaction of the user with the user interface. (c) Describe each dialog window in detail (layout, properties of the controls etc.) (Did I miss anything?) (Ad 4) I have more than ten years of experience with enterprise software. I am browsing tables almost on a daily basis. Thus, I think I have a good understanding of what a (power) user needs and wants. On the other hand, I don't know the source code of OOo and I do not plan to implement the new filter dialog. This is one reason why I also need a developer in the i-team (which need not be the person to actually implement the filter later). I am not familiar with the procedures with OOo projects. Thus, I need some support in this regard. Since writing this specification will require some effort on my side, I wouldn't like it to be in vain. So I hope to find the necessary support (i.e. an i-team) so that the new filter will likely be integrated into OOo in the not so distant future... -Karl Am Sonntag, 1. März 2009 23:02 schrieb Frank Schönheit - Sun Microsystems Germany: > Hi Karl, > > > So I _could_ start...? > > Definitely. Of course the more people you involve, especially from UX > the more chances the specified changes will ever become reality :) > (And of course, the more people you involve, the more difficult it will > become due to the lot of different opinions :) > > > I guess I have to use the specification template for > > Writer. > > Matter of taste. > > Personally, I find writing specifications in the Wiki more difficult > with regard to the involved work in actually writing, on the other hand, > the Wiki has its advantages (the online version is always up-to-date, > corrections/additions can easily be made by other parties, etc.). > > The Wiki template can be found at > http://wiki.services.openoffice.org/wiki/Specification_Template > (unfortunately not linked from > http://wiki.services.openoffice.org/wiki/Specification). > > > On [2] I found some other things that need to be done/checked before I > > start: > > In general, do not impose too much meaning into those requirements (but > don't cite me on that :). > > > (-- denotes a quote) > > > > --Q1 [Feature/Enhancement] > > --Does an unambiguously clear feature or enhancement request exists? > > > > Well, does one exist? I hope the description in [1] is enough to fullfill > > this request. If not, what has to be done? > > For this item, like for the others, the following holds: It is *one* > possible mean to ensure a certain pre-requisite. There are other means, > and case-depending, you might choose one of the others. (That's my > personal interpretation, but it worked well in the past :) > > > What this requirement wants to ensure is that all involved parties have > the same understanding of the goal. > > In fact, this requirement is *very* important, and not fulfilling it is > a main reason for specification failures. If you specify something which > doesn't address the needs others have, this doesn't help at all. > > What I found extremely useful in the initiation phase of the feature is > to hold a meeting with all stakeholders (however you define that), and > to ensure that they all know and agree what the project is about. > Luckily, I could do this in person often enough, for your purpose I > would suggest an IRC meeting. > > So: gather the people which you want to work with on the feature, e.g. > the ones which should give you feedback while the spec evolves, ideally > also the ones who will later (probably) implement and QA the feature. > Make sure you want the same thing. Make sure that if you say "the > current dialog sucks", they all do not only nod, but you find out *why* > it sucks, to make it better. Else, you'll notice when you finished the > spec that you all had different understandings of "it sucks". > > Then go for it, and ignore Q1. > > (Such gatherings can be useful in various stages of the process, so > don't think it's over after the initial "kick-off" meeting.) > > > --Q2 [Concept]: > > --For changes requiring modifications in more than one application: Is > > --there product concept available, which is understandable to the > > --intended readership? > > > > I guess, this is irrelevant > > Yes. > > > since only one application is concerned: Base. > > and also since Produce Concept Documents are an relict from early times ;) > > > --Q3 [Project-Resources]: > > --Do you have a project team? An OpenOffice.org feature is always > > --being developed by an Implementation Team (i-Team). An i-Team consists > > --at least of two distinct persons: > > > > -- * A developer (required) > > -- * A QA representative (required) > > -- Ask for a QA representative in the d...@qa.openoffice.org mailing > > list. -- * A User Experience member (required only if the feature or > > bug -- fix affects the user interface or the behavior of the > > application) > > > > This is my first problem. How do I get this i-team? I have to specify > > their names in the spec. I can ask for a QA representative as described, > > but where do I get a developer? And how do I get a User Experience > > member? > > Ask around :) > > preface: One thing you need to be aware of is that it is well possible > that you write the perfect specification for a perfect feature, but > nobody will be able to pick it up for development, for whatever reasons. > Ideally, it won't happen this way, but nobody can guarantee that. If > this doesn't scare you, go on ... > > Having said that ... ignore the developer for the moment. Since you do > not know who will later on implement it, you cannot invite the implementor. > > Which doesn't mean that you cannot ask (in d...@dba - oh, this is where > we currently are in :) core developers to join, if you want. They are > often able to give hints about cool features in the spec which are hard > (up to impossible) to implement in the current OOo infrastructure, and > you certainly want to know those to raise your spec's chances of being > implemented ... > > Similar things hold for QA. > > Having more user ex members ("more" because I assume that you have a > certain user ex affinity, else you wouldn't offer to write a spec) is > always a good thing. Again, asking is what gives you answers/volunteers. > disc...@ux is a good place. I of course could recommend Chris Lukasiak > to you, who happened to take the UX role in the Base team after our > previous UX expert left for other tasks. > > Personally, I am immodest enough to offer my help in the Dev as well as > UX area, though I fear I haven't as much time to spend for the project > as I would like to have. > > > --Q4 [i-Team Agreement]: > > --Do all i-Team members agree on Q1 - Q3? > > > > Well, first I need these three people... > > > > --What happens if I can't answer all questions mentioned above, with Yes? > > --The consequence could be that your valuable work won't be integrated > > --into OpenOffice.org. > > > > So, at the moment I should better not start.... or should I? > > You should. > > I consider a specification a very good means to plan a feature, to stay > in contact with the stakeholders (which is very important, see above), > to ensure that all the time all of them see the same big picture ... I > do *not* consider a specification and end in itself, as I do not > consider the Qs an end in themselves - if you can reach what they (the > Qs, and on a higher level the spec itself) want to ensure by other > means, then Just Do It (TM). > > > Although it might > > not be necessary to meet all these requirements as long as only the spec > > is going to be written, it would be a good idea to involve at least a > > User Experience member. > > Yes. > > Ciao > Frank --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org For additional commands, e-mail: dev-h...@dba.openoffice.org
