Tags:
create new tag
, view all tags
Allow me to show you two examples, among others, on which “unmercifully” refacorization is not convinient.

  • Recently I read PeterThoeny ´s TWikiPresentation21Jan2004 and followed a link to a IBM´s tool (http://researchweb.watson.ibm.com/history/) that graphically depict the version evolution of some pages at Wikipedia. (It´ll be nice to have that tool available on twiki). I was somehow worried about vandalism that erases or heavely modify the sense of most of the previous contributions. The same IBM study shows that somehow the page rolls back to the previous state pretty soon, mainly due to the rapid reaction of the current contributors , very little harm is done. As anybody can always re-state to a previous “good” version, a non regular visitor always will be wondering if the current state is the “good” or the “vandalized” one. Should He/She check one of the previous versions to see if the “good” one is somewhere in the past versions? Does He/She have the time?

  • In the online twiki manual, all comments must be appended to the end of the page in order so not to spoil the carefully tailored content of the subject being documented.

Wouldn´t it be nice to have a way to avoid these effects?. I propose the following:

I´m taking the liberty to give a try to a tool used in some quality systems, it is called AMEF table, the current one is a modified/simplified one. Not the place to extend on AMEF but I would say that worthwhile to use it in future brainstorming or bug reports.

Ack! This horizontal layout makes it very difficult to read when the amount of content in the tables cells varies greatly from column to column. Also, if we're going to use large tables like this, might I suggest we install RecursiveRenderPlugin on twiki.org to ease the formatting of the table contents? I'm going to change it to a vertical layout...see if you think it's an improvement. -- WM

You are right, this way is way more readable, and perhaps it what is really needed in cases like the ones handled in twiki. A drawback of this arrangement is that sometimes there is more that one cause , or effect, and as a consecuense more than one wayaround of proposeed control for each cause or effect and it would be difficult to match what what solution applies to what effect, and what its RPN (Risk priority number) number will be. I should have wrote FMEA (Failure Mode and Effect Analisys in ensglish)instead of AMEF (Analisis de Modo y Efecto de la Falla in spanish). The original FMEA table is larger, you may see an example at http://www.npd-solutions.com/fmea.html. This is the table arrangement I must use at work. You may see now why I needed YetAnotherTableSyntaxRequest. Again I think your refactoring is in order in this case.-- AntonioVega - 07 Mar 2004

AntonioVega, I looked at the tables in the tutorial by Crow. To implement this on a twiki, I would suggest the following strategy:

  • Make every row a topic and put the information into the form
  • Assemble the table through a query
  • If you are ambitious, use SpreadSheetPlugin (or write your own) to avoid rendering a cell if the cell above would have the identical content (for the first three rows of the assembled table).
  • Create a link with each row which immedately edits the topic associated with that row.

Suddenly the individual cells become more manageable, and in addition, you can have discussions associated with each row, or additional information. It is fine if the table is wide, as you only read it when you want to see the whole table (and in that case you want it in the appropriate format).

The other alternative would be to use SimpleTableEntryUsingForms, and thus to keep all table rows in a single topic. Again, I would favor the original table layout over the one below. This alternative is not possible on TWiki.org, as this addon is not installed.

Either way, you do not want to edit these tables within a topic using the standard text area, this would drive you crazy and invite mistakes. Note: I was not sure whether this comment is appropriate in this topic; you might want refactor the discussion on how to lay out the FMEA table to another topic?

-- ThomasWeigert - 07 Mar 2004

Function affected Content management
Failure Mode, wish, example or failure mechanism Digested/regulated content modified in a sense not originally intended.
Example: TWiki user manual main documentation mistakenly overwritten in restricted section.
Cause Vandalism, carelessness, negligence, slip, oversight, error, mistake
Effect Doubt about having the information under convenient control.
Current control Copy a previous validated version (probably in raw view) and paste it in the current one

Or use INCLUDE variable in a other "controlled" topic (on which modification is allowed by the interested ones) that refers to a specific validated version.
Proposed Control First some variables must be in order: ALLOW(DENY)WEBDIGEST (under webpreferences)ALLOW(DENY)TOPICDIGEST (on the topic itself) Which might be assigned to users or groups. The content can be secured by mean o the following:

%STARTDIGEST%
Content regulated by all allowed users (or, of course, by the sys admin group)
Bla
Bla
%STOPDIGEST%

%STARTDIGEST{User}%
Content regulated by a particular allowed User (or, by the sys admin group)
Bla
Bla
%STOPDIGEST%
Basically , the preview script should notify a fault and avoid update if there is a modification in the regulated sections, or the ALLOW(DENY)TOPICDIGEST authorization variable within a page, or mofification on webs with ALLOW(DENY)WEBDIGEST. However, it should allow the modification in other non restricted sections of the same page.

Perhaps it is not really needed if we stick to one of the wayarounds.
Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2004-03-07 - ThomasWeigert
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.