MSO's 80/20 rule: 80% of the people use about 20% of the functionality.

users
#1

A paragraph that points to pcmag.com's article about "100 Essential Tips for Microsoft Office 2010" list the following "rule":
[quote]
For most of the world, Microsoft Office 2010 follows the 80/20 rule: 80% of the people use about 20% of the functionality.
[unquote]

That 80% that is not used by the 80% of the users is what MSO advertised a few years ago that these were the most needed options by users and were most of the advertised "thousands of new functions added" for their next upgraded product. I was told once that of that 80% not used, about 90% of that figured features are used by only 1% of MSO's users. Can anyone spell B.L.O.A.T.

I hope LibreOffice never has that type of rule applied to their office suite. The extensions solve many of the functions that are needed by the small percentage of users. We do not need them to be installed by default. We do not need to be able to do spreadsheet functions in a Writer document, but I was told that Word can do that if you knew how to do it properly. That is bloat for rarely function used concept and should not be in a wordprocessing document. Copy/Paste a spreadsheet into a Writer document is OK, but we do not need to bring all of Calc's function over to Writer so you can user Writer for Calc work.

#2

Hi :slight_smile:

Lol, i can't believe they are advertising one of the key reasons we give to
people for walking away from MSO. Obviously every single user believes they are
in the 1% that uses too many of the advanced features and so could not possibly
walk away.

The specific example of not needing spreadsheet functionality inside the
word-processor is not great. It does explain the point but LibreOffice (and
OpenOffice) are more tightly integrated then MSO so the functionality is easier
to reach without it really being 'inside' the wrong app. At least that's the
impression i have.

Regards from
Tom :slight_smile:

#3

the fact is that the 20% used isn't the same for everybody, for example I use function from 1 to 20 and my friend from 3 to 23 and another friend from 6 to 26, so in the world every function is used by some 20%, this is the why libo' isn't so diffused and used, becouse you can easily find something that you use in office that isn't present in libo'. :-))

#4

Hi :slight_smile:

No, i think the point is that of that same 20% not everyone uses all of that
20%. Yes people use different features from each other but all the features
they use tend to be fairly basic ones, eg not macros and almost none of the
formulas in Excel. It's all very imprecise of course.

Regards from
Tom :slight_smile:

#5

webmaster for Kracked Press Productions <webmaster@krackedpress.com>
writes:

The extensions solve many of the functions that are needed by
the small percentage of users. We do not need them to be installed by
default.

Spreading things across too many packages (that one can optionally
install) isn´t so great, either: because when you look for a particular
functionality and don´t find it in the minimum set of packages you do
have installed, it makes you easily figure that the particular
functionality you´re looking for isn´t available at all.

We do not need to be able to do spreadsheet functions in a
Writer document, but I was told that Word can do that if you knew how
to do it properly.

Well, I do like it very much that I have spreadsheet functionality in
org-mode of emacs ... If emacs had libre office functionality, I´d use
it instead of libre office.

#6

Hi All,

Hi :slight_smile:

No, i think the point is that of that same 20% not everyone uses all of that
20%. Yes people use different features from each other but all the features
they use tend to be fairly basic ones, eg not macros and almost none of the
formulas in Excel. It's all very imprecise of course.

Regards from
Tom :slight_smile:

________________________________
From: yahoo-pier_andreit <pier_andreit@yahoo.it>
To: users@global.libreoffice.org
Sent: Fri, 17 June, 2011 16:01:29
Subject: Re: [libreoffice-users] MSO's 80/20 rule: 80% of the people use about
20% of the functionality.

>
> A paragraph that points to pcmag.com's article about "100 Essential Tips
> for Microsoft Office 2010" list the following "rule":
> [quote]
> For most of the world, Microsoft Office 2010 follows the 80/20 rule: 80%
> of the people use about 20% of the functionality.
> [unquote]
>
> That 80% that is not used by the 80% of the users is what MSO advertised
> a few years ago that these were the most needed options by users and
> were most of the advertised "thousands of new functions added" for their
> next upgraded product. I was told once that of that 80% not used, about
> 90% of that figured features are used by only 1% of MSO's users. Can
> anyone spell B.L.O.A.T.

the fact is that the 20% used isn't the same for everybody, for example I use
function from 1 to 20 and my friend from 3 to 23 and another friend from 6 to
26, so in the world every function is used by some 20%, this is the why libo'
isn't so diffused and used, becouse you can easily find something that you use
in office that isn't present in libo'. :-))

==================================================
MESSAGGIO ISTITUZIONALE

Investi nel futuro. Investi nelle nostre ricerche.
Destina il 5 x 1000 all'ENEA
Cerchiamo:
- nuove fonti e nuovi modi per produrre energia pulita e sicura.
- modi migliori per utilizzare e risparmiare energia.
- metodologie e tecnologie per innovare e rendere piu' competitivo il sistema
produttivo nazionale.
- metodologie e tecnologie per la salvaguardia e il recupero dell'ambiente e per
la tutela della nostra salute e del patrimonio artistico del Paese.
Il nostro codice fiscale e': 01320740580

-- Unsubscribe instructions: E-mail to users+help@global.libreoffice.org
In case of problems unsubscribing, write to postmaster@documentfoundation.org
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

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. The used features are not
necessarily bloat but should be available either with the package or as
extensions. The selection of which are included is probably best left to
the programmers. I suspect some are easier to added as extensions while
others are best included in the package.

#7

Hi !

  I think the most import is that there are several kinds of users, at
least in OpenOffice.org and LibreOffice. Some of them use some features
as statistical funcions; other use pivot table or macros ... as examples
in CALC. Same in Writer, Base, Impress and others. Exceptions users use
a lot of features at the same time ... but is so important to have "on
hand" all that features because if you need one of them you only have to
click for using... that is great at least for me ... I didn't use all
the features but I 've used much of them in some different moments since
I use Open Sourse office suites.

Regards,

Jorge Rodríguez

#8

planas <jslozier@gmail.com> 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?

#9

Sorry, but that example was the only one I remember seeing that was too weird to forget.

I know many "high-end" users that need those limited user functions to do really "weird" things that I would not have though possible in Word or Excel. Those users are the type that could write books on the least know functions of those packages and tell you why you cannot live without using them.

What the "average" user, either business or home, needs from an office suite is what LibreOffice gives then very well. The more complex you make your documents with more complex functions and formulas for spreadsheets, the harder it is to use a package. It may be even harder to write those options for the packages than to use them.

It is nice to have one package that will open up the different modules like word processing and spread sheets. Having to install complete packages for each carries a lot of duplication of code and much more file space on a hard drive. But I really do not want my word processor to do high end spread sheet work or image editing. I would rather have those functions in different packages [separate install files] or separate modules of the unified package [like LibreOffice].

Sure, there is a need to write a package to will give the 20% user base what they need. But sometimes MS seems to go overboard adding 100's or even 1000's of new functions whether the user needs/wants them or not.

#10

Lee,

planas <jslozier@gmail.com> 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. 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.

Another problem is I do not know how easy or difficult it is write the
code of specific features. I suspect some are very straightforward while
others require a much deeper knowledge of the program.

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.

#11

this reminds be of a conversation I had with Microsoft people back in 2000. I'm disabled, I use speech recognition and quite frankly liberated office is not terribly speech recognition friendly (including its name). The conversation I was having with Microsoft was about speech enabling Microsoft Word. They kept coming up with these really huge unmanageable grammars to try and make every GUI elements accessible. I said "but I only use 10% of word" to which they replied "so does everybody else. The problem is they all use a different 10%"

I don't know if it's comfort to know that you're suffering from the same problems as Microsoft Word and there really isn't a very good way to solve the problem.

What I do in a speech interface is I try very hard to isolate grammars based on context and maybe that's the kind of thing you need to do. Yes, you will have cases where you have two ways of saying the same thing in two different contexts but it can't be helped.

and for what it's worth, to do good speech user interface (i.e. not something nuance gives you), it's becoming apparent to me that you need a backdoor interface giving read/write access to all GUI/plug-in accessible data. Then the speech user interface can present the information and operations in a UI appropriate context.

#12

Very few people know this, but OS/2 Warp was light years ahead of
current Windows products with its speech technology.

#13

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. 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.

this reminds be of a conversation I had with Microsoft people back in 2000. I'm disabled, I use speech recognition and quite

I have a speech problem [Dyslexia and 3 strokes] that MS's software could not be trained to recognize properly. So I know what it is like to need good options for the disabled user. My neighbor has M.S. and her hands can barely control a mouse, let alone type on a keyboard. I was told that Dragon Speak[?] is the best of the Windows software but it needs fast systems and good resources to work properly. I was told that it should work with LibreOffice.

frankly liberated office is not terribly speech recognition friendly (including its name). The conversation I was having with Microsoft was about speech enabling Microsoft Word. They kept coming up with these really huge unmanageable grammars to try and make every GUI elements accessible. I said "but I only use 10% of word" to which they replied "so does everybody else. The problem is they all use a different 10%"

I don't know if it's comfort to know that you're suffering from the same problems as Microsoft Word and there really isn't a very good way to solve the problem.

What I do in a speech interface is I try very hard to isolate grammars based on context and maybe that's the kind of thing you need to do. Yes, you will have cases where you have two ways of saying the same thing in two different contexts but it can't be helped.

and for what it's worth, to do good speech user interface (i.e. not something nuance gives you), it's becoming apparent to me that you need a backdoor interface giving read/write access to all GUI/plug-in accessible data. Then the speech user interface can present the information and operations in a UI appropriate context.

Grammar issues and words that sound similar to the software - ant/aunt Ann/an/and is one of my problems with Speech software, even with a lot of training of the software.

#14

Yes I agree, you dont' know when you need a function so if you find it at glance instead of install is very better than install it, nowdays disk space are very cheap:-))

#15

planas <jslozier@gmail.com> writes:

Lee,

planas <jslozier@gmail.com> 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?

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.

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?

And what about one of the most important features: being able to create
a text or a spreadsheet or a presentation or some other kind of document
you can still use 20 or 60 years later?

#16

planas <jslozier@gmail.com> writes:

> Lee,
>
>
>> planas <jslozier@gmail.com> 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.

> 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?

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.

And what about one of the most important features: being able to create
a text or a spreadsheet or a presentation or some other kind of document
you can still use 20 or 60 years later?

The problem is the fact many documents were produced on abandon ware or used deprecated file formats, eg old MS Word or Excel formats.

Some of the problem is caused by users switching programs but doing the
tedious chore of converting the old files to a newer format. Another
problem is the obsolete storage media used. How many people have the
ability to read a 3.5" floppy let alone a 5.25" floppy or old zip disks.

Another issue is the life span of the storage media, most will degrade
with time.

The solution to file formats being unreadable is to use backward
compatible formats that allow the opening of the older formats. But then
you have the problem of how far back you must go for backward
compatibility. It helps to use open/standard formats rather than
proprietary formats, but this is still a partial solution.

#17

planas<jslozier@gmail.com> writes:

<snip>

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.

<snip>

I think that the use of Extensions for the functions that are not used very often [or rarely], or by few users, is the way to go. I see some old extensions that were created to add functions before they were added to the package.

If there is a need for a function for Calc, Draw, Writer, etc., then maybe creating an extension is the proper route to go.

There is a movement to make a replacement for Oracle's report builder extension. I do not think anyone would tell you they would want that report builder a default, internal, function of LibreOffice. That type of function is useful as an extension.

To be honest, you could make a lot of the seldom used or rare functions or options into extensions so the user can pick and choose to add it to their LibreOffice install. Just like all the language dictionaries, if you do not need "Lower Sorbian" than you do not need it built into the package. When you do need it, then install the dictionary extension for it.

#18

My thoughts were to allow extensions for very specialized needs that
only a few users need or want.

I sometimes think there should be a method of proposing possible
features and selecting those that will included. How this should be done
I do not have suggestion at the moment.

#19

planas<jslozier@gmail.com> writes:

Lee,

planas<jslozier@gmail.com> 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

#20

The problem is that the programmers _never_ test with the extensions,
so, when they make changes, the extensions quit working. Then the
"maintainer" quits maintaining the extension. You want a shining
example? Download, install, and try the SUN Weblog Publisher.