FeatureMatrix

From AbiWiki

Current revision as of 21:30, 14 February 2011

AbiWord Feature Matrix

This first draft of this page is aimed at brainstorming ways to approach and present the "current" status of AbiWord, by feature.

Im thinking Id like to present a big table or a summary table with sub-tables (perhaps on other pages) something like this:

Major items like styles, footnotes, tables (and others I havent thought of yet) would be main headings / features. Beneath some (or all) of those items we might list detailed features related to the previous item. I cant think of a good example immediately, but to make one up, suppose table cells only work with a plain white background -- a detailed feature might be "cells with colored background" and would provide a chance to report on specific aspects of a feature.

Part of what Im trying to say is that, at some point in time we might consider the table feature finished, but cells still might not be allowed to have colored backgrounds -- we might report the table feature as complete, but beneath it would be the "cells with colored background" and it might show as "no", and not even be planned.

That is not the only reason to show these details. Too often I read that a software package has such and such a feature, and I go to try it out, and find that while they have some feature that could (fairly or unfairly) be called the feature I was expecting, it is often much less than I expected. These detailed subitems would give a user more of a flavor of what the "main" feature really includes.

I guess I could write another note -- in general, once a feature shows up, we should expect that it will not be removed in a future release. However there are exceptions. I would propose that once yes appears in a column indicating a feature has been included, we wont repeat yes for every subsequent release, but only (by exception) report no if the feature has (intentionally) been removed in a later release.

If I start this effort, I know I will need lots of input to attempt to keep it up-to-date. (And it seems like the developers are in the best position to do so.) I wonder if they are interested at all. (Being this is a wiki, it can be done very collaboratively, after an initial set up period (establishing a baseline of current features) updates will occur only as:

• A developer makes progress toward adding a new feature
• A user recognizes that the description of a feature was not fine grained enough, in that a (sub) feature he expected as part of a feature does not exist
•  ???

Hmm, I can also see a need for notes. Not sure how Ill present those. Two examples might be:

• Table text can be imported into AbiWord even at the 1.0 release (from any (most, some??) formats that AbiWord can import, but the text is presented as one line per cell.

• View codes as implemented in Word Perfect is not quite as necessary for AbiWord as for some other word processors, for two reasons:
  • You can view the AbiWord XML markup by viewing a file in a plain text editor or viewer.
  • <probably controversial and requires more explanation> If you use the styles feature, and use it carefully, you will have less need to view codes -- you will get most of the information you need by recognizing which style has been applied to a portion of text and then checking the characteristics of that style on the __ __ __ menu.

_Far aside: Before I use a word like span for the users, I should provide a(n accurate) definition. (Assuming I have an accurate definition -- first cut: a span is a contiguous portion of text with exactly the same attributes applied to it. (I guess there could be degenerate spans -- I would think a "normalized" span is the longest contiguous section of text with exactly the same attributes.))_

Resources

Listing some sources for information for this page:

• Heres the future source of the 2.0 HackDown (from Eric Zen)

Contributors

• Main.RandyKramer - 16 Jan 2003