Joerg Barfurth wrote: >> Casually, I was readig issue 39486 before reading this.
http://qa.openoffice.org/issues/show_bug.cgi?id=39486
There you have another example of existing functionality that is wasted due to deeply wrong and biased usability scenario.
The strange usability scenarios may have played a minor role in the things that happened with that specification. But in the first place this is something where there was a real usability problem. If I get a document from someone else (e.g. by mail) it should not open at a seemingly random place in the middle. This may utterly confuse less experienced users.
Then, that person should have unchecked the options box. I don't know why SO many people, not just you, don't get this. If someone wants there doc to open at the top you had the option. If I want to continue editing a 40 page doc in the middle, I had the option.
So changing something here was indeed necessary.
Yes, the final execution was lacking. I just don't understand how whoever decided this would write a spec, say we will remove this feature, but we will add a shortcut to to make it work for those that need it and then just abandon the shortcut and now the issue is labeled OOo Later. Will it happen in a future 2.0.x or are are talking 3.0?
Perhaps this thread can be let die, but I think that this thread can be a very valuable experience for future decisions. I do not consider it as a fighting, but a clarification of the way user-developer communication. So, I will add moore, just for future study.
I see this issue 39486 a good example of let's say "developer overwork" (no injury meaning, I know that many people, myself, dot their best and with the best will). To solve the perceived problem, drastic code changes are prescribed to remove an existing function, impose a new dafault bahaviour (now OO documents to start always at first page) and develope a completely new funtionality, the new shorcut, to do what was already possiblle is nothing was touched, in the first place.
A better, analysis would had indicated that if you simply let the option, that was there, to choose between starting at page 1 or last editing point, the ONLY change needed was to set the value of that option as "1st page" on default. In that way unknown documents would open at first page for all users. But if a user goes to change the option to "last edit point", then you cannot consider that user a newby. He will not be confused if he receives a 50 pages document and it opens at last page due to "lazyness" of the author who forgot about going top start before saving (as the usability scenario suggest). This approach would have required much less programming hours, saving resources for really new improvements.
Let's acccept that the final desired behavior is "opening at page 1 + shortcut to last edit point". The pathway I am describing has another advantage: incremental advance with backward compatibility.
a) Change existing options defaults to better approximate to the desired behavior (what I have described above)
b) Make the new funcionality: put a programmer to code the new shorcut, and have the shortcut working
c) Now, and only now, you can remove the existing functionality
But here the pathway was the opposite: first remove a working thing, in the hope it will be replaced by new function, that delays and is not incorporated. And you get naked in the cold
Scarcity of developing resources is no news. All decisions should be aware of that: never remove without the replacement in hand. I would think that should be standard practice, common sense.
This whole thread reveals the need for a role as "designer" (that I thought was existing). This is a not-so-technical role (not about manipulating pointers, interfaces or internal data structures, but with a good knoledge of it), that identifies user problems and requested new functions, translating user-POV to developer-POV.
This job-role understand the problems the users need to solve to accomplish a task. They put in the shoes of the user with a problem-solving mind, trying to find the best way to do it with existing OOo. In this way functionality and usability lacks are identified. If new ways of doing thins simpler arise, those are communicated to developer for implementing.
Furthermore, Those people are not living in the moon. OOo newsgroups are populated by quite a bunch of individuals that know a lot of user complains and requests. Individuals that do try, daily, to explain to newbies how to do things with OOo (different that MSO, KOffice or others), and know what confuses newbies and what
This thread has revealed that few or no developers read these newsgroups, even that comments in IZ are perceived as "distracting" (at least). Perhaps heavy duty coders should not read it daily, but I think someone MUST, and then digest and translate to developing instructions: spec doc.
The suggestion by Daniel Carrera is a good one. If those anouncement spec doc are posted here, someone will read them and there will be a greater possibility that wide discussions arise. The next step is digesting such discusions, making a final point and posting it again. This is a crucial step: knowing that decisions have been taken (either accepting o rejecting proposals)
And the general discussion list is *the* way to do that, not some obscure list. General users, newbies, and those that daily help to newbies in this list are the target for that discussions. Do not ask people to subscribe to a dozen lists: at the end it will be you and you cat discussing in a no-one-care list.
Please, have a look at Python community and web site. It's probably a smaller project, but it's standards of transparent decision making rules, community contribution and communication are the higest I know of. (and I do not mean every body and you cat having access to the CVS). What I like most there is the high level of *design* decisions.
- Enrique -
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
