On Sun, 2011-06-19 at 11:09 +0200, Frieder wrote: > Am 19.06.2011 01:52, schrieb planas: > > On Sat, 2011-06-18 at 10:39 +0200, lee wrote: > > > >> planas<[email protected]> writes: > >> > >>> Lee, > >>> > >>> On Fri, 2011-06-17 at 21:42 +0200, lee wrote: > >>> > >>>> planas<[email protected]> writes: > >>>> > >>>>> I believe that the 80/20 is somewhat misleading. As noted earlier must > >>>>> use approximately 20% but not the same 20%. > >>>>> > >>>>> I would estimate that somewhere around 50% of all the features are used > >>>>> reasonably often and the rest are rarely used. > >>>> There are substantial features 100% of the users use, aren´t there? > >>>> What´s the percentage of such substantial features compared to all > >>>> features? > >>>> > >>>> If substantial features make for 20%, you would have 80% percent of all > >>>> features of which 50% are rarely used. If I´m not mistaken, that makes > >>>> already 60% of all features used reasonably often. When you need to make > >>>> a package that provides 60% of all available features, you might find > >>>> that there´s another 20% or 30% of all available features that need to > >>>> be packaged as well because of dependencies. > >>>> > >>>> When you need to package 80--90% of all features anyway, how > >>>> important is it to put effort into packaging only 10--20% of all > >>>> features seperately? > >>>> > >>> The current problem is we do not have any good information of what > >>> features are not very important and do not extend the functionality for > >>> all but a few users. The question is what mix of included and extensible > >>> features should be available beyond those that are important. > >> Which features are important? > > Beyond the basic file manipulation, you have the basic data > > entry/handling needed for each application. The features, many wlll > > probably be included are useful for some but not all users. > > > >>> One of the problems is you need either a lot different users surveyed > >>> at the same time or smaller number surveyed over a longer period of > >>> time. For example, most of the time I do not use a table of contents > >>> in my documents but when I need the feature I must have it. How many > >>> people need this feature irregularly versus those that often use it? I > >>> do not know. > >> There you go: When you need a particular feature, you must have it. When > >> you need it, it is totally irrelevant how often you or other users use > >> it. > >> > >> How often a feature is used and/or how many users use it doesn´t say > >> anything about how important the feature is. When someone needs it, it > >> has to be there. > > I would disagree, it takes time to code and debug a feature that is very > > rarely used by a small number users. These features may better added as > > extension. The problem is where to draw the line and say this one is > > included and this one will be a possible extension. > > > Partially I agree to your argument, but as you can see in this > mailing-list, a lot of problems appear because the programmers have not > in mind, that their new code is not compatible to some extensions. > If these extensions were included in LO they would find these bugs > before the relic of a new version, and not weeks ore months later like > it is today. > >>> One of the marketing tricks is tout all the features you have in your > >>> package without regard to how useful many are to all but a handful of > >>> users. Look carefully at some the commercial software ads and notice how > >>> often they tout features that look nice but you probably will never use. > >> What´s worse? Having features you don´t need often or not at all in the > >> software you use or having to look for other software you don´t use and > >> that has the particular feature (and maybe not others) you happen to > >> need (maybe only once ever) and use that instead? > I totally agree to that. There are a lot of functions I did not use at > the beginning when I started to work with spreadsheets, because I did > not know that thy were included. > The more I learned about all the functions, the more I'm going to use > them. But up to now I did only Install two Extension. 1'st the > dictionary, witch I think is a good choice to putt this in an extension. > And second the "X-Ray tool" (A really helpful debugging toll, to learn a > lot about Programming in LO), which I think should be included in the > main packages. > If a function I really need is not included in the main package, I'm not > going to start a long (and often unsuccessful) search for extensions. > I write( if possible) a macro or my own function instead. But not all > users are able to use macros, and it took me a while to learn to handle > them the way I'm doing this now. > This method has two ore three advantages: It is often faster then > looking for the right extension, and the document is compatible to other > LO installations, where no extensions are installed. This is important, > if you want to sheer the document. > Also the function is exactly what I need and not something close to what > I need. > > > This will always be a problem for any software package. It is impossible > > to provide all the possible features that may get used very rarely. > > Also, it is very difficult to determine in advance all the ways users > > will find for the software. That is partly why macros are important, > > they provide a possible method to provide really unusual features at the > > cost of the user needing to know some programming. > > > Yes I think macros are really important. And there is still a big > potential (and in my opinion need) in improving the macro features. > for example an auto-completion like the one in MS-VBA would bee really > great and would make the macrowriting a lot faster , easier and easier > to learn. > In star-Basic I need almost twice as much code as in VBA to get the same > results. The macro-recorder is not really helpful because he didn't work > in most cases, and is always using the "uno instructions" instead of the > regular methods. (I know there is another Extensin to translate the uno > instructions into normal code, but it would bee much better if this > would bee kart of LO, because many users don't that this ad-on exists, > and therefore don't use it.) > > regards Frieder > > > > > > >
The main concern is there needs to a method to determine what should be included as feature. There will be features that are left out of a particular release that one could argue should have been included instead of one that was included. This is ongoing problem with no easy answers. The reason for the selection is time, every feature will take time to properly develop, debug, etc. and if you are going to make any release schedule you will need to select which ones are included and possibly which ones are deprecated. The issue about being able to open older file formats is a current problem. Simplistic answers such as move to a new hard drive, etc. ignore the fact that no one expected to need the old files or that no (new) hardware would have the capability of using the old media. Factor in harddisk crashes and you can have real problem. Add to the hardware problems is that many of the old file formats were proprietary. When the vendor went out of business or stopped supporting the product others slowly stopped supporting conversion to other often proprietary formats. It has been relatively recently that various open/ISO file formats have been developed that partially alleviates the problem -- Jay Lozier [email protected] -- Unsubscribe instructions: E-mail to [email protected] In case of problems unsubscribing, write to [email protected] Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
