planas <[email protected]> writes:
> On Sat, 2011-06-18 at 10:39 +0200, lee wrote:
>
>> planas <[email protected]> writes:
>>
>> >
>> >>
>> >> 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.
Let me claim that how many users use a feature isn´t a good indicator,
if one at all, of the importance of a feature. You could use the most
simple editor, or use echo, to put together a text document[1]. You can
also use some software that has more features, and users might learn
about the features and start using them. Still the fact that someone
uses a feature doesn´t make this feature important[2].
Instead, we could agree upon that it always depends on the task at hand
and on the user performing the task what features of a software used to
perform that task are important[3].
[1]: Look so many years back, and software, like word processing
software, didn´t have as many features as it does today. Look back
a little further, and there wasn´t any software at all involved in
word processing.
[2]: Are cell phones important? No, not at all; only a lot of people
use them nowadays and think they are important, though mankind has
done without them most of the time.
[3]: That includes features not even there (yet), like footnotes :)
>> 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.
Sure it takes time to implement a feature. How much a feature is used
doesn´t have any effect on how much it takes to implement it, or does
it? The same is true for extensions, I guess.
Why is there a need to draw a line?
>> > 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.
>>
>> 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.
It doesn´t matter how much a feature is used, it´ll still be hard to
implement all possible features into some software.
To draw a line between what features a software should provide and which
ones not, istn´t it better to look at the purpose of the software rather
than at how much a feature is actually used or not?
> 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.
When someone wants to use a feature of a software, I think it´s only
reasonable to expect of him to learn how to use the feature. Macros are
just another feature allowing users to automate something or even to
implement their own features. It´s only convenient to have features
available that are ready to use.
>> 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.
That isn´t too difficult to solve by just having all your data in
current storage.
> 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.
Yeah, unfortunately there really isn´t any good long term storage
format. One cannot make sufficiently reliable predictions about the
backwards compatibility of future storage methods, so backwards
compatibility is kinda only an illusion and might better be
omited. Converting should be made easier ...
--
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
