On Wed, 26 Jan 2005 23:56:55 -0500, Chad Smith <[EMAIL PROTECTED]> wrote:
[snip]
> Good night.... It's not about being like "the other guy" - it's about
> accepting *universal* standard operating practices. Aren't we all about
> "standards" here? It's about meeting users expectations. It's about
> providing the user a clean interface that makes sense and isn't flooded
> with thousands of text-only options that fill 52 pages....
I want to see this standard! perhaps you can point me to a
standard/specification that explains why any one app should only have
X number of options.
Why because if that were so then, theoretically, we could contact MS
and tell them that their Windows XP has too many options via the
registry and they should eliminate all but 1500 of those options. Only
the elite professional users in the business world, and the 'hard
core' MS Geeks use them. So we should get rid of them.
Essentially OpenOffice has a 'registry' of sorts; A database with alot
of options for customization of OpenOffice. At this point, however,
the only way we have of editing those things is through the
preferences dialog and possibly some command line utilities that have,
(I think) a very steep learning curve. Some users do not use turning
off the screen, solely using the screen saver in Windows, so should an
options relating to that particular feature be rermoved, just because
some users see it an annoyance, possibly a bug, not a feature for
them? What about the registry settings to customize the title bar of
Internet Explorer? True it may not seem common on the face to change
the title bar in Internet Explorer, but you'd be surprised the number
of utilites that allow you to do just that, because a lot more people
than those that speak up believe it's a feature.
You might love the stylist and another user thinks that this is
incorrect and the universal standard is to do hard styling and so
should OOo. Should we remove this for them? No absolutely not.
So, though you may believe such and such is not a feature and should
be removed, and another person believes it is a feature and should
not, and still another user doesn't care one way or the other and will
take the default, and still another user bags OOo and goes a
competitor (like say MS Office, or Corel, or something else) because
it doesn't offer the options like they'd like, the latter two don't
make a difference as they'll do what they will and should be ignored.
Also, we should not cater to either of the first parties, but find a
middle ground, a compromise. We must allow both to do what they want
how they want.
To do think this is the solution that I've seen brought up, but will
require some work, and YES, I UNDERSTAND THAT THIS WON'T FLY FOR 2.0,
however, we are body that has influence into the making of OOo, and so
should work together to make sure things happen.
The following things should probably be done:
1) None of the features should be removed, or if they've been removed,
a plan should be made to reinstate them in a way that meets the rest
of what needs to be done.
2) The old preference UI should be hidden and a new one put in it's place.
2) It should be decided (by whom? see below) which options are most
used and should be in that UI.
3) This UI should be very GUI oriented with eye candy and easy to
navigate for beginner users
4) An additional component should be created to do in depth preference
database editing.
Such a component would need the following:
A) Be able to view all of the information stored in the database
as well as edit any options that are safe to edit.
B) As noted elsewhere, the database contains a lot of
information on what the options are for and so descriptions should be
included for every option.
C) Perhaps a database connector could be created to make it so
we can use Base to 'edit' the database? I'm not sure on this one.
D) All of the options should be organized effeciently
E) As we're doing this we might want to create(enable?) a shared
preferences type thing where a shared preferences can be defined here
and put on a server. I talked about this in another e-mail.
F) This preference component should be accessed from one (or
both) of the following:
i) Create Options submenu:
* Tools>
* Options> //Click here to open the
basic preferences UI or wait for sub menu
* Main Options //Or something like
this for the basid preferences UI
* Advanced Preferences Database
Editor //To access the new component
ii) This should also be accessible via an option somewhere
in the basic preferences for "Advanced Preferences Database Editing"
or something to that effect.
5) Another possibility (as Charles Marcus suggested) is to make the
basic GUI customizable. Users can reposition and move stuff around
wherever they want. This would have to be accessed via the Advanced
Preferences Database Editor most likely, but would make people even
happier.
So who should decide what options go where? How things should be
organized? ...? ...? etc...?
I believe we should create some kind of committee "TPCC" The
Preferences Component Committee or something like that. This committee
would use community surveys, discussion on mailing lists (possibly
creating a new preference list) and IssueZilla to determine which
options are in the Basic Preference UI, or which ones should not be in
the same UI.
The preferences component would have some (a lot) of developers then
go through and implement, in close proximity with the above committe
the new UI components for the preferences.
Number 5 is a very good idea though and still other UI
editing/customization component(s) would have to be created. This will
bump such development even further and possibly reduce the amount of
effort that the committee would have to do to decide the default basic
preferences. I think I read somewhere something about dialog boxes
being made to be dynamically sized for localization and such, possibly
both could be combined somehow to reduce the overhead and the
additional resources required in OOo. It would also be great if this
particular component were made so that it were not dependent on OOo
and could be used in other FLOSS apps.
Such changes will take a LOT of effort, and the ideal would be for
sun, or some other corp to provide a developer either part time or
full time to oversee this and make sure it goes through. This is not
simple undertaking and so won't make 2.0, however shooting for 3.0
would be good. We could have the major thing for 3.0 be enhanced
preferences, just as OpenDocument seems to be one of the biggest
things fro 2.0. Again, this is MAJOR and will need a lot of work.
So, yes as Chad said:
> The fact is, the choice has been made. The official build will be the
> way they will be - and we can waste hours and bandwidth until hell
> freezes, and that's not going to change the fact that those two options,
> for good or ill, are gone --- or changed ---- or whatever they really
> are. Unless you "roll your own" or write a macro or find a work around,
> you can either use 2.0 or not. It's up to you.
We can't make it in 2.0 and what's done is done. We can waste a lot of
time bickering about this, or (the better alternative) we can pull
together as a community and make sure that such problems don't happen
again, or else have the framework and channels through which to get
the changes to preferences to happen.
I don't have the time to learn how to develop, however I'd be willing
to help with getting this committee, or whatever is decided upon *as a
community* in order to make this happen. I may not have a lot of time,
but something has to be done. So let's raise a kind of "title of
liberty" to save all the options for our country, our organizations,
our families, and our selves! (I'm curious to know if anyone on the
list knows what book I'm alluding to? ;-) If you don't, don't worry
about it right now.) We can call the committee the Title of Liberty of
options. :-)
Thanks for OOo.
Jacob Floyd
PS I think most of this makes sense however I added some stuff that
might make it not quite as clear after I read some other users (very
good) suggestions.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
