HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


Possible Errors on Wiki+ page rendering

Login / Search

 [ Join | More ]
 Add topic 
Posted
Rating:
#92411 (In Topic #18529)
Avatar

Well-settled

I noticed a couple of issues with the Wiki+ page rendering.

1) I noticed that there seem to some issues with the Table of Contents again.  Chris did some work on this before in relation to one of my questions, but maybe a subsequent fix to something else broke it.  If you go to this page (http://www.bawiki.com/pg/s/219/190?redirected=1) you will notice that the Contents block only has 3 entries, but if you scroll through the (long) page there are actually 8 level one headers and another 5 level 2 headers.

2) I also noticed that while editing a page in the WYSIWIG editor that a "QUOTE" tag is rendered as the teletype effect in the edit page, even though it is rendered correctly once the page is saved. 

Thanks
Back to the top
 
Posted
Rating:
#92413
Avatar

1- maybe you set the tag's 'levels' parameter to restrict the depth

2- it is normal to indicate Comcode-tagged portions of what is shown in the editor


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#92418
Avatar

Well-settled

Chris,

1.  Nope, no levels value.  Even if I had set it to one, shouldn't it have shown all 8 of the level 1 items instead of just 3 of them?

2.  I'm not sure I understand your point here.  If the WYSIWIG editor was showing it with the outline box that is rendered when you save I would understand.  I was just curious why it shows as TELETYPE while being edited, and then with the quote box once saved.  It may not be an error, I just thought it was weird that it acted in different ways between the editor and the saved results when it wasn't an explicit comcode like the "Contents" tag (at least, I don't think it is).

Thanks
Back to the top
 
Posted
Rating:
#92419
Avatar

1– I need you to report the exact Comcode used here in a 'codebox' tag, so we can see. You can strip out the text between the headers if you like.

2– If it showed complex Comcode tags using the rendering styles, the WYSIWYG editor would end up losing the Comcode tags and save out HTML tag soup. Therefore only Comcode tags that map to primitive HTML are displayed as such, because those can always be converted back consistently.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#92420
Avatar

Well-settled

Here is the first line of the Wiki+ page that includes the contents flag:

Code

 [semihtml][contents][/contents]
Back to the top
 
Posted
Rating:
#92421
Avatar

I'll need the full Comcode, so that I can understand the title structure properly, and how the titles have been encoded.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#92422
Avatar

Well-settled

Sorry, I have no idea what you are asking for.  Does this mean I need to open a tpl file or something?  I know you know what you want, but I'm still figuring out the basics and have no idea what the difference is between a comcode tag that gets put in a page and the "full comcode".  I opened the page, turned off wysiwig, and that is what is there.

It's nearly 3am where I am and 2am where you are.  I'll worry about it tomorrow.
Back to the top
 
Posted
Rating:
#92430
Avatar

Go to edit the page, turn off the WYSIWYG editor, select all the page text, copy it to the clipboard, come back here, start a reply, choose to add a code tag, paste in inside the code tag.

i.e. I need all the Comcode, not just the contents tag. Otherwise I cannot see what your exact title structure is. Looking at the resultant HTML isn't sufficient.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#92455
Avatar

Well-settled

Here you go:

Code

[semihtml][contents][/contents]
<hr />
<h1>
   Introduction</h1>
The Waterfall method is a Systems (or Software) Development Life Cycle (SDLC) that seems to suffer from a vast amount of confusion about what exactly it is and what exactly it entails. Its harshest critics have equated the &quot;Waterfall method&quot; with the whole concept of a Systems Development Lifecycle (SDLC) and described as a &quot;toxic concept&quot;. [4] These critics describe what I call &quot;pure&quot; Waterfall, since it is undiluted by any other concepts, flexibility (or historical accuracy IMO).<br />
<br />
So what is &quot;pure&quot; Waterfall? &nbsp;It is supposedly defined by the following characteristics:
<ul>
   <li>
      It is a sequential, highly-planned (some would say rigidly planned) process consisting of several phases</li>
   <li>
      Each phase is a silo, completely separate from the other stages, with the output of one stage being the input into the next</li>
   <li>
      Each phase must be completed with 100% certainty before the project team moves on to the next phase. [5]</li>
   <li>
      It &quot;ignores end-user development and end-user involvement outside of requirements specification&quot; [4]</li>
   <li>
      It &quot;assumes human developers are capable of correctly getting the requirements, design and tests correct on the first try.&quot; (emphasis mine) [4] and that requirements can never be changed once the requirements phase is complete. [5]</li>
   <li>
      It &quot;separates analysis from design&quot;, forcing developers to &quot;generate a solution, without providing any guidance as to how the solution is generated&quot;. [4]</li>
</ul>
This concept is usually modelled in a visual way with an image such as this (similar to the one used on Wikipedia):<br />
<br />
&nbsp; <img alt="" src="http://www.bawiki.com/uploads/galleries/Widipedia_Waterfall.png" title="" /><br />
<br />
There are lots of references to this &quot;pure&quot; waterfall methodology, especially from &quot;Agile&quot; proponents, but I cannot find a single person who has actually ever used a pure waterfall process in a project, and so far I cannot find a single paper that espouses the &quot;pure&quot; waterfall methodology that is commonly described. From what I can tell, &quot;pure&quot; Waterfall exists only in the imagination.<br />
<br />
So if you take a less hysterical view, what exactly is the &quot;Waterfall method&quot;? And like many other things in life, the answer is &quot;it depends on who you ask&quot;. For many people, the Waterfall method exists only as the &quot;pure&quot; form above. But based on my reading of the literature (mostly covered below), I would say that in general the &quot;Waterfall&quot; method is an SDLC that has the following characteristics:<br />
<ol>
   <li>
      It consists of a number of sections in which specific activities are accomplished in a sequence.</li>
   <li>
      These sections can overlap and be revisited once complete, but generally the results of one activity feeds into the next.</li>
   <li>
      The overall cycle is completely executed no more than 2 times. If executed more than once, the first cycle is for the creation of a prototype.</li>
   <li>
      The process is documentation heavy, specifying a number of documents be created during the entire cycle.</li>
   <li>
      Once development begins, a formal change-control process must be used.</li>
   <li>
      Quality Assurance is integrated by splitting each stage into two parts: the first part executes the work of the stage and the second part validates it.</li>
</ol>
<br />
Please note that the above description does NOT mean that once phase must be 100% complete before the next phase can be engaged.&nbsp; What it means is that in general, if you want to do analysis, you need to have something to analyze. So the results of a Software Requirements activity (there can be multiple activities) would be the input to an Analysis activity, which would in turn be the input into a Design activity.<br />
<br />
This results in what I call a &quot;Modern&quot; Waterfall model that looks something like the below. Note that the Requirements, Analysis, and Design phases are a sub-cycle that run until there is a &quot;final&quot; baselined set of requirements. The requirements include the software requirements document, the interface requirements document, and the technical design specification document. Occasionally, the work involved in creating these documents may generate changes to the overall system requirements which then feedback into the sub-cycle. Once this sub-cycle has generated the &quot;final&quot; requirements documentation, coding and testing can get underway. In order to control change, scope creep, and costs, any changes from this point forward go through a formal change control process (a Change Review Board in most of the literature).<br />
<br />
<img alt="" src="http://www.bawiki.com/uploads/galleries/Modern%20Waterfall.png" /><br />
<br />
<h1>
   Origins</h1>
The origins of the Waterfall model are usually ascribed to papers by Herbert D. Bennington in 1956 [1] and Winston W. Royce in 1970. [2] &nbsp;However, this attribution becomes difficult when the papers cited are actually read. &nbsp;Neither author uses the term &quot;Waterfall&quot; in their papers anywhere. &nbsp;The Bennington paper does describe a very top-down, highly sequential process that advocates for planning out the application in the greatest degree possible before a single line of code is written. &nbsp;However, the Bennington model is not entirely sequential and the steps consist of: Planning -&gt; Specification Creation (with different specifications for the Machine, the Operations, the Program, and the Coding process) -&gt; and Testing (with separate Parameter testing, Assembly testing, Shakedown, and System Evaluation phases).<br />
<br />
In assessing the Bennington paper though, the modern reader has to remember that it was written at a time when higher-level programming languages were just coming in use (most coding was still done in Assembly) and programs were still stored mostly on punch cards (with some tape use). &nbsp;You also have consider that there were no development tools, no code libraries, no consistent coding standards, and they were looking at costs to write a program in the neighborhood of $50 per instruction. &nbsp;Given those costs in 1956, it&#39;s no wonder they were trying to accomplish as much design and specification ahead of time as possible.<br />
<br />
Further, the &quot;responsibility&quot; for the wide-spread adoption of the Waterfall methodology is usually attributed to (or blamed on) its adoption by the US Department of Defense with DOD Standard 2167, the MILITARY STANDARD: DEFENSE SYSTEM SOFTWARE DEVELOPMENT, published on June 4, 1985.<br />
<br />
[title param=&quot;1&quot;]The Royce Models[/title]<br />
The second paper, and the one most frequently cited as the source for the Waterfall methodology, is the paper by Winston W. Royce in 1970. &nbsp;This attribution becomes very confusing if you actually read the paper, or even look at it beyond the second Figure that Royce provides. &nbsp;However, for anyone who only looks at the second Figure, it becomes easy to think that Royce is responsible for the &quot;Waterfall&quot; method as it is commonly understood. &nbsp;A recreation (with color) of that second figure is shown below:<br />
<br />
<img alt="" src="http://www.bawiki.com/uploads/galleries/Traditional%20Waterfall.png" title="" /><br />
<br />
<br />
Royce is using this figure as an example of a high-level concept. &nbsp;He describes it as:<br />
<br />
[quote]A&nbsp;more grandiose approach to software development is illustrated in Figure 2. &nbsp;The analysis and coding&nbsp;steps are still in the picture, but they are preceded by two levels of requirements analysis, are separated by a&nbsp;program design step, and followed by a testing step. &nbsp;These additions are treated separately from analysis and&nbsp;coding because they are distinctly different in the way they are executed. &nbsp;They must be planned and staffed&nbsp;differently for best utilization of program resources.[2][/quote]<br />
<br />
That sounds like &quot;traditional&quot; waterfall. &nbsp;But that completely ignores the very next line after the quote above and it&#39;s accompanying figure. &nbsp;The next paragraph immediately after the above quote is:<br />
<br />
[quote]Figure 3 portrays the iterative relationship between successive development phases for this scheme. &nbsp;The ordering of steps is based on the following concept: that as each step progresses and the design is further detailed, there is an iteration with &nbsp;the preceding and succeeding steps but rarely with the more remote steps in&nbsp;the sequence. &nbsp;The virtue of all of this is that as the design proceeds the change process is scoped down to&nbsp;manageable limits. &nbsp;At any point in the design process after the requirements analysis is completed there exists&nbsp;a firm and closeup, moving baseline to which to return in the event of unforeseen design difficulties. &nbsp;What we&nbsp;have is an effective fallback position that tends to maximize the extent of early work that is salvageable and&nbsp;preserved.[2][/quote]<br />
<br />
So Royce was saying that the process represented above is an iterative development process. &nbsp;He just uses the first Figure to show the overall flow of the concept. &nbsp;He then goes on to show Figure 3 (as indicated in the quote) which does include the iterative process in the diagram. &nbsp;That diagram is recreated below:<br />
<br />
<img alt="" src="http://www.bawiki.com/uploads/galleries/Royce%20Criticized%20Waterfall.png" title="" /><br />
<br />
<br />
<br />
Royce then goes on to discuss that while he believes in this iterative development process, he feels it tends to only iterate each step with the immediately prior step. &nbsp;This he feels may limit the processes ability to react to issues discovered that may require a larger potential change. &nbsp;He indicates that issues found during Program Design may require revisiting the Software Requirements (not just Analysis), that options found in Testing may require revisiting the Program Design or possibly even the Software Requirements, and the iterating through the entire cycle again to adjust to whatever issues were discovered. &nbsp;He shows the effect of his suggested changes by referencing Figure 4 in his paper, recreated below.<br />
<br />
<img alt="" src="http://www.bawiki.com/uploads/galleries/Royce%20Recommended%20Waterfall.png" title="" /><br />
<br />
<br />
But even this is not the process Royce is finally recommends. Royce then goes on to suggest the following five (5) step process:
<ol>
   <li>
      <strong>Program Design Comes First:</strong> A preliminary program design phase has been inserted between the software requirements generation phase and the analysis phase. This procedure can be criticized on the basis that the program designer is forced to design in the relative vacuum of initial software requirements without any existing analysis. As a result, his preliminary design may be substantially in error as compared to his design if he were to wait until the analysis was complete. This criticism is correct but it misses the point. By this technique the program designer assures that the software will not fail because of storage, timing, and data flux reasons. As the analysis proceeds in the succeeding phase the program designer must impose on the analyst the storage, timing, and operational constraints in such a way that he senses the consequence..... If the total resources to be applied are insufficient or if the embryo operational design is wrong it will be recognized at this earlier stage and the iteration with requiements and preliminary design can be redone before final design, coding and test commences.</li>
   <li>
      <strong>Document the Design</strong>: During the early phase of software development the documentation is the specification and is the design. Until coding begins these three nouns (documentation, specification, design) denote a single thing. If the documentation is bad the design is bad. If the documentation does not yet exist there is as yet no design, only people thinking and talking about the design which is of some value, but not much. The real monetary value of good documentation begins downstream in the development process during the testing phase and continues through operations and redesign. .... Following initial operations, when system improvements are in order, good documentation permits effective redesign, updating, and retrofitting in the field. If documentation does not exist, generally the entire existing framework of operating software must be junked, even for relatively modest changes.</li>
   <li>
      <strong>Do It Twice:</strong> If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations areas are concerned. .... In either case the point of all this, as with a simulation, is that questions of timing, storage, etc. which are otherwise matters of judgment, can now be studied with precision. Without this simulation the project manager is at the mercy of human judgment. With the simulation he can at least perform experimental tests of some key hypotheses and scope down what remains for human judgment, which in the area of computer program design (as in the estimation of takeoff gross weight, costs to complete, or the daily double) is invariably and seriously optimistic/</li>
   <li>
      <strong>Plan, Control, and Monitor Testing:</strong> &nbsp;&quot;Without question the biggest user of project resources, whether it be manpower, computer time, or management judgment, is the test phase. It is the phase of greatest risk in terms of dollars and schedule. It occurs at the latest point in the schedule when backup alternatives are least available, if at all. The previous three recommendations to design the program before beginning analysis and coding, to document it completely, and to build a pilot model are all aimed at uncovering and solving problems before entering the test phase. &quot; Royce then goes on to suggest some specific actions for the test phase:
      <ol>
         <li>
            With good documentation it is feasible to use specialists in software product assurance who will, in my judgment, do a better job of testing than the designer.</li>
         <li>
            Every bit of an analysis and every bit of code should be subjected to a simple visual scan by a second party who did not do the original analysis or code.</li>
         <li>
            Test every logic path in the computer program at least once with some kind of numerical check.</li>
         <li>
            After the simple errors (which are in the majority, and which obscure the big mistakes) are removed, then it is time to turn over the software to the test area for checkout purposes.</li>
      </ol>
   </li>
   <li>
      <strong>Involve the Customer:</strong> For some reason what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble.</li>
</ol>
The recommendations result in the following &quot;Waterfall&quot; diagram that Royce provides. This is what I call the &quot;Original&quot; Waterfall and is actually what Royce recommends and proposes in his paper:<br />
<br />
<br />
<img alt="" src="http://www.bawiki.com/uploads/galleries/Original%20Waterfall.png" style="width: 1035px; height: 729px" /><br />
<br />
<br />
<br />
<h1>
   DOD Standard 2167</h1>
So if Royce did not describe the &quot;pure&quot; or &quot;traditional&quot; Waterfall methodology, where did it come from? The next culprit named is usually the U.S. Department of Defense, which supposed adopted the Waterfall methodology in DOD Standard 2167, and in doing so &quot;forced&quot; it upon the rest of the world. And if you look at page 2 of the standard document, it sure looks like the military has adopted the &quot;traditional &quot;Waterfall method when you see this diagram:<br />
<br />
<img alt="" src="http://www.bawiki.com/uploads/galleries/DOD-2167_System%20Process%20Flow.png" style="width: 747px; height: 678px" /><br />
<br />
<br />
<br />
The diagram seems to be implying a linear, sequential process, with no iteration and revisiting prior stages. This potential understanding is not helped if the reader skims through the document looking for the description of the Software Development Cycle, which proscribes the following steps:
<ol>
   <li>
      <strong>Software Requirements Analysis.</strong> The purpose of Software Requirements Analysis is to completely define and analyze the requirements for the software. These requirements include the functions the software is required to accomplish as part of the system, segment, or prime item. Additionally, the functional interfaces and the necessary design constraints are defined. During Full Scale Development, and Production and Deployment, this phase typically begins with the release of the SSS [System/Segment Specification], Prime Item Specification(s) , Critical Item Specification(s), or Preliminary SRS(s) [Software Requirements Specification] and IRS(s) (Interface Requirements Specification), and terminates with the successful accomplishment of the SSR. During this phase, analyses and trade-off studies are performed, and requirements are made definitive. The results of this phase are documented and approved requirements for the software. At the initiation of Software Requirements Analysis, plans for developing the software are prepared or reviewed (as applicable) .</li>
   <li>
      <strong>Preliminary Design.</strong> The purpose of Preliminary Design is to develop a design approach which includes mathematical models, functional flows, and data flows. During this phase various design approaches are considered, analysis and trade-off studies are performed, and design approaches selected. Preliminary Design allocates software requirements to TLCSCs, describes the processing that takes place within each TLCSC [Top-Level Computer Software Component], and establishes the interface relationship between TLCSCs. Design of critical lower-level elements of each CSCI may also be performed. The result of this phase is a documented and approved top-level design of the software. The top-level design is reviewed against the requirements prior to initiating the detailed design phase.</li>
   <li>
      <strong>Detailed Design.</strong> The purpose of Detailed Design is to refine the design approach so that each TLCSC is decomposed into a complete structure of LLCSCs [Lower-Level Computer Software Components] and Units. The detailed design approach is provided in detailed design documents and reviewed against the requirements and top-level design prior to initiating the coding phase.</li>
   <li>
      <strong>Coding and Unit Testing.</strong> The purpose of Coding and Unit Testing is to code and test each Unit of code described in the detailed design documentation. Each Unit of code is reviewed for compliance with the corresponding detailed design description and applicable coding standards prior to establishing internal control of the Unit and releasing it for integration.</li>
   <li>
      CSC Integration and Testing. The purpose of CSC [Computer Software Component] Integration Testing is to integrate and test aggregates of coded Units. Integration tests should be performed based on documented integration test plans, test descriptions, and test procedures. CSC Integration test results, and CSCI test plans, descriptions, and procedures for testing the fully implemented software are reviewed prior to the next phase of testing.</li>
   <li>
      <strong>CSCI Testing. </strong>The purpose of CSCI testing is to test the fully implemented CSCI [Computer Software Configuration Item]. Testing during this phase concentrates on showing that the software satisfies its specified requirements. Test results should be reviewed to determine whether the software satisfies its specified requirements.</li>
</ol>
<br />
Of course, you have to skim all the way to pages 69 and 70 to find that description. And in doing so, you may skip over the many indications that the military did not specify the &quot;traditional&quot; Waterfall model at all, by missing such statements as:
<ol>
   <li>
      &quot;This standard is intended to be dynamic and responsive to the rapidly evolving software technology field. As such, this standard should be selectively applied and tailored to fit the unique characteristics of each software acquisition program.&quot; Page iii, item 2</li>
   <li>
      &quot;During software development, more than one iteration of the software development cycle may be in progress at the same time. Each iteration represents a different version of the software. This process may be described as an &ldquo;evolutionary acquisition&rdquo; or &ldquo;incremental build&rdquo; approach. Within each iteration, the software development phases also typically overlap, rather than form a discrete termination-initiation sequence. For example, performing Unit code and test concurrently with CSC [Computer Software Component] integration and test is useful in implementing incremental builds. &quot; Page 11, item 4.1.2</li>
   <li>
      &quot;<strong>The phases in the software development cycle may involve iterations back to previous phases</strong>. For example, design may reveal problems which lead to the revision of requirements and reinstitution of certain analyses; checkout may reveal errors in design, which in turn may lead to redesign or requirements revision; etc.&quot; Page 69, item 20.4.5.1</li>
   <li>
      &quot;<strong>The contractor shall use a top-down approach </strong>to design, code, integrate, and test all CSCI&#39;S (Computer Software Configuration Item), <strong>unless specific alternate methodologies have been proposed </strong>in either the SSPM [Software Standards and Procedures Manual] or SDP [Software Development Plan](see Appendix D) <strong>and received contracting agency approval </strong>(see 6.2).&quot; Page 16, item 4.8</li>
   <li>
      &quot;The contractor may depart from a top-down approach to: (1) code and test critical Units or (2) incorporate commercially available, reusable, or Government furnished software.&quot; Page 32, item 5.4.1.3</li>
   <li>
      &quot;These activities <strong>normally proceed in such a way that testing of selected functions begins early during development </strong>and proceeds by add ing successive increments to the point where a complete CSCI is subjected to formal testing.&quot; Page 67, item F, discussing software coding and testing, software integration and testing; software formal testing, system integration and testing.</li>
   <li>
      &quot;It <strong>includes one or more major iterations of the software development cycle</strong>. The intended outputs are a system which closely approximates the production item, the documentation necessary to enter the system&rsquo;s Production and Deployment phase, and the test results that demonstrate that the system to be produced will meet the stated requirements. <strong>During this phase the requirements for additional software items embedded in or associated with the equipment items may be identified</strong>. These requirements may encompass firmware, test equipment, environment simulation, mission support, development support, and many other kinds of software.&quot; Page 65, item 20.4.3, the &quot;Full Scale Development&quot; description.</li>
</ol>
<br />
A more detailed examination would also show that the Software Development Cycle is described as being part of a larger System Development Cycle that is not captured in the diagram shown above. The description the System Development Cycle stages is enlightening. It states:&nbsp;<br />
<ul>
   <li>
      &quot;The system life cycle consists of four phases: Concept Exploration, Demonstration and Validation, Full Scale Development, and Production and Deployment.
      <ul>
         <li>
            <strong>Concept Exploration</strong>. The Concept Exploration Phase is the initial planning period when the technical, strategic, and economic bases are established through comprehensive studies, experimental development, and concept evaluation. This initial planning may be directed toward refining proposed solutions or developing alternative concepts to satisfy a required operational capability.
            <ul>
               <li>
                  During this phase, proposed <strong>solutions are refined or alternative concepts are developed </strong>using feasibility assessments, estimates (cost and schedule, intelligence, logistics, etc.), trade-off studies, and analyses. The SSA [Software Support Agency] and user should be involved in these activities.</li>
               <li>
                  For computer resources, <strong>the software development cycle should be tailored for use during this phase </strong>and may result in demonstration of critical algorithms, breadboards, etc.</li>
            </ul>
         </li>
         <li>
            <strong>Demonstration and Validation</strong>. The Demonstration and Validation Phase is the period when major system characteristics are refined through studies, system engineering, development of preliminary equipment and prototype computer software, and test and evaluation. The objectives are to validate the choice of alternatives and to provide the basis for determining whether or not to proceed into the next phase.
            <ul>
               <li>
                  During this phase, system requirements, including requirements for computer resources, are further defined, <strong>and preferred development methodologies for computer software and data bases are selected</strong>. The results of validation activities are used to define the system characteristics (performance, cost, and schedule) and to provide confidence that risks have been resolved or minimized.</li>
               <li>
                  For computer resources, the software development cycle should be tailored for use during this phase, resulting in prototype software items.</li>
            </ul>
         </li>
         <li>
            <strong>Full Scale Development</strong>. The Full Scale Development phase is the period when the system, equipment, computer software, facilities, personnel subsystems, training, and the principal equipment and software items necessary for support are designed, fabricated, tested, and evaluated. It includes one or more major iterations of the software development cycle. The intended outputs are a system which closely approximates the production item, the documentation necessary to enter the system&rsquo;s Production and Deployment phase, and the test results that demonstrate that the system to be produced will meet the stated requirements. During this phase the requirements for additional software items embedded in or associated with the equipment items may be identified. These requirements may encompass firmware, test equipment, environment simulation, mission support, development support, and many other kinds of software.
            <ul>
               <li>
                  Software requirements analysis is performed in conjunction with system engineering activities related to equipment preliminary design. SRSs and IRSs for each CSCI are completed and authenticated at the SSR, establishing the Allocated Baseline for each CSCI. Requirements for software that is part of an HWCI [Hardware Configuration Item] may be authenticated during HWCI design reviews. The OCD [Operational Concept Document] is completed and reviewed at the SSR as well.</li>
               <li>
                  A preliminary design effort is accomplished and results in a design approach. For computer software, preliminary design includes the definition of TLCSCs in terms of functions, external and internal interfaces, storage and timing allocation, operating sequences, and data base design. Detailed design of critical lower-level elements of the CSCI may be performed as well.</li>
            </ul>
         </li>
         <li>
            Production and Deployment. The Production and Deployment Phase is the combination of two overlapping periods. The production period is from production approval until the last system item is delivered and accepted. The objective is to efficiently produce and deliver effective and supported systems to the user(s). The deployment period commences with delivery of the first operational system item and terminates when the last system items are removed from the operational inventory.
            <ul>
               <li>
                  After a system is in operational use, there are a variety of changes that may take place on the hardware items, software items, or both hardware and software items. <strong>Changes to software items may be necessary to remove latent errors, enhance operations, further system evolution, adapt to changes in mission requirements, or incorporate knowledge gained from operational use</strong>. Based upon complexity and other factors such as system interfaces, constraints, and priorities, control of the changes may vary from on-site management to complex checks and balances with mandatory security keys and access codes. ...... The same six phases of the software development cycle are utilized for each change during the Production and Deployment phase (see Figure 4).&quot;</li>
            </ul>
         </li>
      </ul>
   </li>
</ul>
<br />
So by reading the specification it would seem that what the DOD actually proscribed was an incremental and iterative process. Where the &quot;strict&quot; Waterfall methodology was proscribed was in the design and coding of each phase of a software component. Not of the entire solution. This is identical to the concept Scrum uses of the development team only working on the specific items chosen for the current sprint and of no one being allowed to change those items while the spring is underway. Note that the DOD standard specifically supports such activities as:
<ul>
   <li>
      Multiple iterations</li>
   <li>
      Prototyping</li>
   <li>
      User involvement in solution design and specification</li>
   <li>
      The discovery of new requirements during and after a software cycle</li>
   <li>
      Testing from very early phases</li>
   <li>
      And even alternative development methodologies</li>
</ul>
In the end, I suspect the same issue occurred with the DOD Standard as with the Royce paper. Namely, people looked at the pictures (or even just the first picture) and did not bother to read the text.<br />
<br />
<br />
<h1>
   The Major Misconception</h1>
Given the above, the exact origin of the misconceived &quot;Waterfall&quot; methodology as it is commonly described is a bit of a mystery. &nbsp;I see this methodology described in many places, but I can&#39;t find an origin for what is commonly described as &quot;Waterfall&quot; in any of the papers that are cited as the &quot;source&quot; of the Waterfall concept. The closest in the Bennington paper in 1956. So the exact origin of the &quot;Waterfall&quot; methodology as it is commonly described is a bit of a mystery. &nbsp;I would go so far as to say that the highly rigid process commonly described as &quot;traditional&quot; or &quot;pure&quot; waterfall has probably never been practiced since the 1960&#39;s or before. &nbsp;Even in 1970 Royce was describing the common software development process of the time as being an iterative process. &nbsp;I don&#39;t know a single BA who has ever been told to use this exact, high rigid, methodology; although I will admit there is certainly that possibility. &nbsp;However, I would argue that such rigidness should not be blamed on a methodology that does not seem to exist beyond an theoretical concept, and that instead the problem in those cases is the people advocating such rigidness.<br />
<br />
<br />
<br />
<h1>
   Waterfall Variations</h1>
<h2>
   Pure Waterfall</h2>
&quot;Pure&quot; Waterfall is the process as it is described by many critics.&nbsp; It involves:
<ul>
   <li>
      A rigidly sequential, highly-planned process consisting of several separate phases</li>
   <li>
      Each phase is a silo, completely separate from the other stages, with the output of one stage being the input into the next</li>
   <li>
      Each phase must be completed with 100% certainty before the project team moves on to the next phase [5]</li>
   <li>
      Users/customers only have input at two phases of the process. In the Software Requirements and Operations phase, after testing is complete.</li>
   <li>
      Once the Software Requirements phase is complete, requirements cannot be changed until after the software is delivered.</li>
   <li>
      Design and development is done based on the requirements documents only. System and development personnel are forbidden from speaking to client or analyst for clarification/follow-up.</li>
</ul>
<br />
<img alt="" src="http://www.bawiki.com/uploads/galleries/Traditional%20Waterfall.png" style="width: 706px; height: 452px" /><br />
<br />
<br />
<br />
<strong>Pros</strong><br />
Relatively predictable cost and delivery timelines since absolutely no changes are considered once requirements are finalized.<br />
<br />
<strong>Cons</strong><br />
TBD<br />
<h2>
   &quot;Traditional&quot; Waterfall</h2>
<br />
<img alt="" src="http://www.bawiki.com/uploads/galleries/Real%20Traditional%20Waterfall.png" title="" /><br />
<br />
<br />
<strong>Pros</strong><br />
TBD<br />
<br />
<strong>Cons</strong><br />
TBD<br />
<h2>
   &quot;Original&quot; Waterfall</h2>
<br />
<br />
<img alt="" src="http://www.bawiki.com/uploads/galleries/Original%20Waterfall.png" style="width: 1035px; height: 729px" /><br />
<br />
<strong>Pros</strong><br />
TBD<br />
<br />
<strong>Cons</strong><br />
TBD<br />
<br />
<h2>
   &quot;Modern&quot; Waterfall</h2>
<br />
<img alt="" src="http://www.bawiki.com/uploads/galleries/Modern%20Waterfall.png" style="width: 615px; height: 326px" /><br />
<br />
<strong>Pros</strong><br />
The strengths of the &quot;Modern&quot; Waterfall process is that there is significant work done before any code is created to think through the business needs, the system design, and as much of the exact form of the solution as possible. This extensive work up front ensures that as many potential problems are found and resolved in advance of coding as possible in defining the solution from both a business and technical perspective.<br />
<br />
The quality assurance aspects of Modern Waterfall wherein the results of each activity are tested/validated at the end of that stage also help facilitate collaboration and customer buy-in since the customer is involved in most of the validation activities (except unit testing during coding). Additionally, the use of formal change control process once coding begins helps limit scope creep and ensures that only changes that are needed are included. Unneeded changes can be discarded or set aside for consideration as part of future enhancement work.<br />
<br />
Lastly, the high documentation needs of the process help ensure that the resulting application is fully understood by future development staff by ensuring that all features are fully documented and that (in theory) any decisions made as to why certain development and design options were pursued or not are also captured. This ensures that when enhancements or changes to the application are considered at a future time that the development can determine why certain decisions were made and whether those decisions need to be re-evaluated or not.<br />
<br />
This method is most useful for complex, highly exacting, software systems where significant architecture changes need to be avoided and where long-term future design factors need to be incorporated early in the process. Examples would include compilers, secure operating systems, or complex financial systems that are affected by significant regulations or high risk factors.<br />
<br />
<strong>Cons</strong><br />
The weaknesses of the &quot;Modern&quot; Waterfall method are that it can be very slow to generate working code and that it&#39;s significant documentation and manpower requirements can result in significant costs. It&#39;s use of a formal change control process can significantly slow the project teams ability to react to change. Because the method does not result in working, usable code until late in the process, issues that may only be found via actual use will not be found until the cost of addressing them is likely to be highest.<br />
<br />
<br />
<h2>
   Iterative Waterfall</h2>
<strong>Pros</strong><br />
TBD<br />
<br />
<strong>Cons</strong><br />
TBD<br />
<br />
<br />
[title param=&quot;1&quot;]Resources[/title]
<ul>
   <li>
      Wikipedia entry: <a href="http://en.wikipedia.org/wiki/Waterfall_method" rel="" target="_blank" title="Waterfall Method: (this link will open in a new window)">Waterfall Method</a></li>
   <li>
      Wikipedia entry: <a href="http://en.wikipedia.org/wiki/Big_Design_Up_Front" rel="" target="_blank" title="Big Design Up Front: (this link will open in a new window)">Big Design Up Front</a></li>
   <li>
      Paper - <a href="http://www.inf.ufes.br/~monalessa/PaginaMonalessa-NEMO/ES_Mestrado/Artigos/ModelosCicloVida-Ruparelia-ACM2010.pdf" target="_blank">Software Development LifeCycle Models</a>, by Nayan B. Ruparelia</li>
</ul>
[title param=&quot;1&quot;]References[/title]
<ol style="list-style-type: decimal">
   <li>
      &ldquo;<a href="http://csse.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83-501.pdf" rel="" target="_blank" title="Production of Large Computer Programs: (this link will open in a new window)">Production of Large Computer Programs</a>&rdquo;, by Herbert D. Bennington. &nbsp;From a presentation at a symposium on advanced programming methods for digital computers sponsored by the Navy Mathematical Computing Advisory Panel and the Office of Naval Research in June 1956.</li>
   <li>
      &ldquo;<a href="http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf" rel="" target="_blank" title="Managing the Development of Large Software Systems: (this link will open in a new window)">Managing the Development of Large Software Systems</a>&rdquo;, by Dr. Winston W. Royce, 1970.</li>
   <li>
      <a href="http://www.everyspec.com/DoD/DoD-STD/DOD-STD-2167_278/" target="_blank">DOD-STD-2167: Defense System Software Development</a>, 4 June 1985,&nbsp;</li>
   <li>
      <a href="http://eprints.lancs.ac.uk/47395/1/Toxic_Concepts_in_Systems_Analysis_and_Design_The_Systems_Development_Lifecycle.pdf" target="_blank">Toxic Concepts in Systems Analysis and Design: The Systems Development Lifecycle</a>, by Paul Ralph (May 2010),</li>
   <li>
      <a href="http://research.ijcaonline.org/volume45/number7/pxc3879113.pdf" target="_blank">A Review of Risk Management in Different Software Development Methodologies</a>, by Hijazi, Khdour, and Alarabeyyat (May 2012).</li>
</ol>[/semihtml]{$,page hint: no_wysiwyg}
Back to the top
 
Posted
Rating:
#92456
Avatar

Right, so I can see here that only the 3 listed ones are defined as Comcode 'title' tags. The rest are defined as raw HTML header tags.
With HTML to Comcode conversion disabled, ocPortal can't recognise these as headers, as ocPortal doesn't analyse/understand HTML when it is processing Comcode, it just puts it straight out.

You'll need to re-enter those h1 tags as Comcode title tags, in the same way you can see the others defined there.

I realise that's a bit inconvenient, it doesn't sit well with WYSIWYG or stuff pasted from Word. But raw HTML is limited (e.g. no way to jump to a header tag via a link), and automated conversion of HTML to Comcode is problematic.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#92458
Avatar

Well-settled

Thanks Chris.

I don't remember the issue that caused me to turn off the HTML to Comcode conversion, but I think it was one of the prior issues having to do with the Contents tag.

Either way, thanks as always for the quick responses.  

But I think before I get any further in adding content to my site that I need to out and re-evaluate what is out there to make sure ocP is still my best choice.  I get the impression that ocP is very forum-oriented with an ok wiki, and I need something more wiki-oriented with a decent forum.

I suspect I'll come to the same conclusion, but I figure I better check before I spend more time trying to add content and figure out the peculiarities of ocP.

Thanks again!
Back to the top
 
Posted
Rating:
#92459
Avatar

I don't remember the issue that caused me to turn off the HTML to Comcode conversion, but I think it was one of the prior issues having to do with the Contents tag.

We recommend to keep this option off, as that's the default. So 'title' tags do need manually inputting if you're using a Table Of Contents.

Regarding the other comments – well, I'd just say even with some complications on more rarely-used features like Table Of Contents generation – it's still a whole lot easier than Wikipedia's editor ;).


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#92460
Avatar

Well-settled

Oh, I agree completely.  MediaWiki was the first app I tried and quickly rejected.

But there were some I disregarded because they weren't included in one of the auto-installers of my web host (like FosWiki or XWiki) or because they weren't integrated (like DotNetNuke) packages like ocP.

Like I said, I suspect ocP will still be the best option, but it will probably mean doing things like turning off the WYSIWIG editor to ensure things like this don't happen, and doing without some of the basic Wiki features I am looking for (like compare versions).  Not to mention trying to figure out all of ocP's quirks (like the complex permissions set up which is spread across multiple screens in the admin menu) and relatively poor documentation.

Those aren't insurmountable barriers, they are just barriers that will take away from what little free time I have already.  As always, I suspect that finding something that EXACTLY fits what I am looking for is not likely to happen.  :)
Back to the top
 
Posted
Rating:
#92464
Avatar

I woke up this morning realising we can do a workaround to this title issue. I'll make it do a conversion only on the HTML header tags, if it detects the Comcode contents tag is in use. That avoids the problems universal automated conversion creates, while targeting the specific issue here exactly.

Here you go:
Attachment
sources/comcode_from_html.php
» Download: comcode_from_html.php (48 Kb, 145 downloads so far)


the basic Wiki features I am looking for (like compare versions)

When you edit a Wiki+ page you can hover over the revision history at the bottom and see diffs of what was changed. You can also choose to restore any prior version. This is both better and worse than MediaWiki: I find the compare version feature on Wikipedia extremely confusing and slow to use, but I appreciate that for long documents our tooltips diffs would not show everything needed. It's definitely an area that could be improved with investment.

like the complex permissions set up

With the need for flexibility, comes the need for some level of complexity. I don't think it's too hard compared to permission schemes in other software (e.g. Windows' ACL system, or other CMSs) – there's the global privileges split into sections, then everything in the Permission Tree Editor. Both give hints about how the more complex permissions work via tooltips that translate the abstract concepts into how it actually applies to content. But suggestions that would make it easier without removing the flexibility are always welcome.

relatively poor documentation

It's disheartening to hear this. For the 12 months or so feedback we've received on the documentation has varied between excellent to poor, but the mode average of the feedback has been it's 'okay'.

Personally I locked myself in a room for about 3 months to write the initial documentation, and its gone through many reviews since then and been added to over time. But we can't compete with some of the higher end commercial groups that have full time writer(s) continuously taking new screenshots and extending it – we just don't have the money coming in to the project to be able to do that.

We do have the community documentation, and I encourage everyone to add to that. In fact, it's prominently in my sig, to encourage people to add to it as they learn things that weren't covered. I'm not sure anyone has ever had a question answered then gone to the community docs to properly document it, so I do find it frustrating. We also have the community project for the book starting up, although currently it's on hold while BobS recovers from his medical therapy.

All I can really say is I wish more users would invest in sponsoring features they need, or in improving the community documentation. There's no free lunches in life and projects like ocPortal depend on users to invest in their projects appropriately. I can keep repeating it forever, but time after time I find people start complex projects with a programming budget of zero, a licensing budget of zero, and a staff team of one, and it does frustrate me a lot because I designed ocPortal to lower costs but not as a panacea. It's human nature to be over-optimistic, and reality for self-starter in-house projects to have no budgets, so what can I do ;-).


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#92493
Avatar

Well-settled

First off, this might sound like I am bashing ocP or you in some places, but that is NOT my intent.  I'm trying to provide some honest feedback.  Feel free to answer as harshly as you feel appropriate.  :)


Chris Graham said

I woke up this morning realising we can do a workaround to this title issue. I'll make it do a conversion only on the HTML header tags, if it detects the Comcode contents tag is in use. That avoids the problems universal automated conversion creates, while targeting the specific issue here exactly.


Thanks, I'll give it a try.

When you edit a Wiki+ page you can hover over the revision history at the bottom and see diffs of what was changed. You can also choose to restore any prior version. This is both better and worse than MediaWiki: I find the compare version feature on Wikipedia extremely confusing and slow to use, but I appreciate that for long documents our tooltips diffs would not show everything needed. It's definitely an area that could be improved with investment.


Chris, a few comments on this:
  • First, I wasn't even aware of this feature.  Going to my comment about the documentation below, as far as I can tell this isn't documented at all.  At least not on the Wiki+ page: http://ocportal.com/docs/tut_cedi.htm
  • Second, this feature is then only available to people who have edit privileges.  But if I am just a reader and see in the Wiki Change Log that "Page X" changed, if I don't have edit privilege, I have no way of seeing the difference.
  • Third, to see this, I have to pull up the edit page view.  That seems like a lot of work just to see the differences.
  • Fourth, if there are number of edits, all you get is a "There are too many differences to display message".  Again, not very useful.
  • Fifth, the pop-up strips out any formatting (at least on mine it does), which makes it very difficult to tell what was changed in the first place as far as the overall context of the page.
With the need for flexibility, comes the need for some level of complexity. I don't think it's too hard compared to permission schemes in other software (e.g. Windows' ACL system, or other CMSs) – there's the global privileges split into sections, then everything in the Permission Tree Editor. Both give hints about how the more complex permissions work via tooltips that translate the abstract concepts into how it actually applies to content. But suggestions that would make it easier without removing the flexibility are always welcome.


My problem with the privileges is the fact that they are split onto multiple pages, and that they seem to interact in odd ways.  For example, I kept having images that I uploaded be flagged as requiring validation, despite the fact that (somewhere) I had set a setting that users didn't need to validate images.  I think I finally resolved the issue by changing the "Bypass validator for mid-impact (medium visibility) content".  To figure out what "mid-impact" content I had to hover over the tooltip launcher.  Putting all of those items under "mid-impact content" is a heck of lot more confusing that just having a single permissions editor for "galleries".

It's disheartening to hear this. For the 12 months or so feedback we've received on the documentation has varied between excellent to poor, but the mode average of the feedback has been it's 'okay'.

Personally I locked myself in a room for about 3 months to write the initial documentation, and its gone through many reviews since then and been added to over time. But we can't compete with some of the higher end commercial groups that have full time writer(s) continuously taking new screenshots and extending it – we just don't have the money coming in to the project to be able to do that.

We do have the community documentation, and I encourage everyone to add to that. In fact, it's prominently in my sig, to encourage people to add to it as they learn things that weren't covered. I'm not sure anyone has ever had a question answered then gone to the community docs to properly document it, so I do find it frustrating. We also have the community project for the book starting up, although currently it's on hold while BobS recovers from his medical therapy.


The biggest problem with the ocP documentation may not be that an answer is not be out there "somewhere", but that it's hard to find an answer.  Or in many cases, the documentation is incomplete. For example, using the Wiki revision history issue above, if I saw that Revision History section on the Edit page and wanted to know what it did, I would come here and search for "Revision History" I get 11 results that all point to forum messages or the "Themeing your Site" tutorial with apparently no reference in the Wiki pages, or anywhere else, that a "Revision History" function exists.

And that same disorganization of information probably effects why the community docs aren't modified very much.  People may feel that since the "information" is essentially found by searching, why not just leave it in the forums which are part of the search function after all?  As a suggestion, you may want to take the content of the "Tutorials" (which is confusing because it's not called "Documentation" and because a "Tutorial" is designed to teach you something, not act as a reference) and put it in each of the Community docs sections so that people can edit it and add further info.  That may make people more comfortable with the process (I'm not saying it will, but it might).  :)

Lastly, I would note that ocP includes what is essentially (as far as I can tell) a Structured Wiki with a tree view, yet the community documents don't leverage that at all.  If I want to see what the 9 items under "Miscellanous Features" are I need to click on that link.  And if what I'm looking for isn't there, but might be under "Content Features", then I need click back, and go look under that link.  I think the main ocP site could do a better job of leveraging the functionality of ocP.  That not only would make it easier to use, but might make ocP more attractive to new users.

And BTW, this reminds of two possible features that might be useful. ;)
  1. The ability to lock specific pages in the wiki from editing unless users have certain permission levels, while leaving other pages editable.
  2. Context aware search boxes.  So that if you are in the wiki/documents area and did a search, that it would just search the wiki pages by default.  Or if you are in the Forums, search the forums, etc.
These two features would let you put all of the documentation (official and community) into one wiki section (with official locked), and it would make searching for info in the documentation much easier.  There doesn't seem to be any way to do a limited search with the main ocP site.


All I can really say is I wish more users would invest in sponsoring features they need, or in improving the community documentation. There's no free lunches in life and projects like ocPortal depend on users to invest in their projects appropriately. I can keep repeating it forever, but time after time I find people start complex projects with a programming budget of zero, a licensing budget of zero, and a staff team of one, and it does frustrate me a lot because I designed ocPortal to lower costs but not as a panacea. It's human nature to be over-optimistic, and reality for self-starter in-house projects to have no budgets, so what can I do ;-).


Believe me, I don't blame you for ocP not being "perfect".  But you also have to look at it from the non-commercial users perspective.  I can "invest" nearly $1000 USD to add a "Create Child Page" button in OCP, or I can take that money and buy a license to a full-blown commercial app which has more features (probably), dedicated support, a bigger coding staff, etc.  Or I can look at alternate open-source applications that may already have that feature and use that $1000 to pay my rent for a month. $1000 is NOT a small amount of money. 

Rather than having users sponsor dozens of little changes, it might be nice if the developers of ocP provided more visibility into the development plans and focused on eliciting sponsorship for the bigger issues that would appeal to the broader array of users.  For example, I'm pretty hesitant to sponsor $1000 to add a "Add Child Page" button, but if you came up with an package that was "modernize the wiki+ functionality" that included a bunch of improvements (both requested and logical evolutions of current functionality that kept pace with other packages out there), then I think you might be more people willing to commit money.  I can't afford $1000, but I can afford to chip in $100-200 maybe in cooperation with others who might want to see those changes.

Also, rather that requiring people to buy support credits FIRST and commit them to specific changes, it might be worth asking for "commitments" from people who are willing to buy a certain number of support credits IF enough other people also agree to support a specific initiative.  This would help you get a better idea of what people might really want (in the form of commitments) and yet you could hold off actual development work until those people actually bought the support credits and fulfilled their "commitment".  It might also get users more enthusiastic about providing support because (hopefully), they would collaboratively funding larger changes.

Anyway, that's my feedback/comments.  Again, I'm not bashing you or ocP.  I think you do a tremendous job as what seems to be essentially the only developer.  And I'm using the software, so obviously I think it's pretty good.  But I do think there are things that could possibly improve the situation.  But that's just my opinion, and others may (rightly) think I am entirely off my rocker.
Back to the top
 
Posted
Rating:
#92495
Avatar

Chris, a few comments on this:
(list of extra desirable features)

This is why it frustrates me so much that 99% of people who use ocPortal don't have a budget to fund the extra features they look for. I'm not aware of a site that has needed the Wiki+ revision history feature as more than a quick reference for page editors, so nothing has funded the development of it so far. If you look at other software with wiki features (not pure wikis) you'll find they don't necessarily have it either.

We really need people to come into the community with a mindset of… "okay, ocPortal is going to cover 70% of the feature points I need", therefore I'll have a reduced programming budget, but still a good enough budget to cover off some extra development. I noticed one of your pages talked in depth about software development methodologies – so I suspect you're familiar with project management, and how much serious projects need to be budgeted ;). I mean, serious projects with a high level of project management discipline, implementing numerous feature points, any serious specification and implementation process would have figures much higher than talked about here. Often technical people underestimate the time it takes to implement things and a disconnect develops, between what they've seen commercial projects cost in the wider world, to what they think they can be implemented for ;).

I know you're comparing to commercial CMSs in terms of price, while I'm comparing to the price of paying a developer to program a website. However, even compared to commercial systems, ocPortal almost always has more features than them as it stands right now. You have to compare like-to-like too, e.g. often commercial systems will charge for extra modules, or charge a high yearly price, or actually have a price more like $10,000 and then expect a system integrator to install it for $60,000. You can look at something like MediaWiki and all its wiki features, and see some are missing in ocPortal – and do that with other classes of software too – but nothing has them all. So trying to compare values like that, it just isn't a fair comparison. The only comparison is that of how much a site would cost if you limited your requirements, to what it would be if ocPortal was extended, to what it would be if it was written by scratch from a programmer. I think ocPortal compares very well there, because as I say even the commercial software is not ahead with features, and the cost to make this level of site from scratch is off the chart in terms of comparison. I understand something like DotNetNuke is very good – it probably has a similar level of features to ocPortal – but it's certainly not a panacea either.

What I'm really saying, is any route, custom programming is needed – even the commercial CMS route. Unless that is a project is fortuitously very aligned with what something else can already do (which is possible – so I think your analysis of other projects is the correct thing for you to do), or if you're willing to install multiple pieces of software and suffer the design/experience fragmentation from that.

Refining my point further, I'm saying, we can't do miracles ;). There's lots of good stuff out there, but we can't draw the best of every feature in from every class of product, and deliver it all for a competitive price. ocPortal does a competent job of the core features common sites want, but it isn't necessarily top of the range in every area, and that's understandable I think.

I also understand fully that most people don't have the budgets for the cost of the features that they want that aren't yet available. In these kinds of situations, users just either need to compromise with a more fragmented system (e.g. installing MediaWiki in a subdirectory), or to cut down their requirements list.

I had set a setting that users didn't need to validate images.  I think I finally resolved the issue by changing the "Bypass validator for mid-impact (medium visibility) content"

If that's true, it sounds like a bug. It is possible you accidentally set it on the root gallery and assumed it would cascade through, which is not something ocPortal does (performance reasons). You'd need to have set it on the galleries module itself, then it would apply to all galleries.

To figure out what "mid-impact" content I had to hover over the tooltip launcher.  Putting all of those items under "mid-impact content" is a heck of lot more confusing that just having a single permissions editor for "galleries".

People often bring this one up, but there are about 35 content types in ocPortal. If each type has 5 privileges, that's 175 privileges to set. As a general software design rule it's good to make the simplest use cases the easiest – in which case, you can set permissions based on how much general kind of trust you're going to give to groups, then users who need fine-grained control can learn how to override using the Permission Tree Editor. I'm sure we could improve what we did, like maybe you press a tree expander button on the global privileges screen to allow further refinement right there, but again, this kind of UI quality takes a lot of time and therefore money.

The biggest problem with the ocP documentation may not be that an answer is not be out there "somewhere", but that it's hard to find an answer.  Or in many cases, the documentation is incomplete.

This is precisely why we need people to fill out the community docs, and why I have it in my sig. If someone asks something fairly general and gets an answer, I'd just hope that they'd then neatly document the answer. Unfortunately most users want questions answered, but don't want to pay for support, or pay for software licenses, and also don't want to contribute back to the documentation. There are clear areas where the documentation could be improved, but unless we can increase user investment in ocPortal monetarily, or in terms of contributions, there's no solution I can do :( [other than remaining a monk the rest of my life – charging just enough for bread, and putting all my energies into development – which since 2004 hasn't been far from reality for me].

As a suggestion, you may want to take the content of the "Tutorials" and put it in each of the Community docs sections so that people can edit it and add further info.

All tutorials are linked through the community documentation also, into the documentation skeleton. If the actual content was copy and pasted, it would quickly get out of sync. If we moved it all over, we couldn't maintain/version it within the development process.

One idea for the future is to integrate Wiki+ and git, so that the Wiki+ is effectively a git frontend and edits are commits. That's a lot of work though, and again there's an issue of funding getting that developed.

I would note that ocP includes what is essentially (as far as I can tell) a Structured Wiki with a tree view, yet the community documents don't leverage that at all.  If I want to see what the 9 items under "Miscellanous Features" are I need to click on that link.  And if what I'm looking for isn't there, but might be under "Content Features", then I need click back, and go look under that link.  I think the main ocP site could do a better job of leveraging the functionality of ocP.  That not only would make it easier to use, but might make ocP more attractive to new users.

Very good point, I have added this suggestion to the tracker for possible future implementation.

These two features would let you put all of the documentation (official and community) into one wiki section (with official locked), and it would make searching for info in the documentation much easier.  There doesn't seem to be any way to do a limited search with the main ocP site.

Please file on the tracker (and perhaps also your enhanced revision history features). However we'd still need to find some way to get development of these features funded.

Rather than having users sponsor dozens of little changes, it might be nice if the developers of ocP provided more visibility into the development plans and focused on eliciting sponsorship for the bigger issues that would appeal to the broader array of users.

The tracker on the site does show what are the most voted for features. In terms of actively promoting development ideas, it's hard enough to get them funded at all, we definitely don't have time to add promotional activities on the front of the time estimates I'm afraid. Things get done as people can pay for them, but I make an extra effort to inject sanity to it, so to the outside observer everything usually seems as if it was planned ;).

Also, rather that requiring people to buy support credits FIRST and commit them to specific changes, it might be worth asking for "commitments" from people who are willing to buy a certain number of support credits IF enough other people also agree to support a specific initiative.

You can do this. It simply says if the sponsorship is backed by credits, or not - the sponsorship is still recorded.

But you also have to look at it from the non-commercial users perspective

I can't fully look at it from non-commercial users perspective I'm afraid, because I need to run a reliable ecosystem for the users, and to run that I need to ensure developers get paid (because a voluntary one is chaos, and that is what many of our competitors do and why ocPortal is itself attractive). My free time is nil.

Btw, I've not been the sole developer of ocPortal, there have been contributions from many people, but perhaps I wrote 90% of it so de-facto I am 'the developer'.

The demand for new functionality, new documentation, free support, etc, is huge. The ability to give it is very low. So my only sensible course of action is to try and foster a realistic sense of how much software development costs, and how the community can pitch in to fill in the holes that can't be done commercially, and set up a framework for that. I can't chase individual requests for things to get done for free. Regarding having holes filled in non-commercially by the community: You can take a horse to water, but you can't make them drink – all our code is on github and Open Sourced, the community docs is ripe for extension, there are many social and sharing features on ocPortal.com ready to be exploited by people in the community, there's an addon framework, and even if ocPortal.com falls short people have the wider web as a classroom/workshop.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#92689
Avatar

Community saint

I apologize for not having more documentation written for Wiki+ Chris.

I have this page:
CEDI Basics - ocPortal

But that page doesn't yet show the more advanced stuff like making tables of contents. If I had that page done, perhaps D-Train would have known how to make the Contents work by using title tags instead of heading tags.

Now, if only my cloning machine would hurry up and get here, so I could get these things done for you…

Legends of Nor'Ova: A site powered by ocPortal; home of the Legends of Nor'Ova tabletop RPG wiki and community.

Like ocPortal? Want to thank Chris and gang somehow? Then help out in the chat room! It really needs your help! Just open it in a tab everytime you open your web browser, and when you hear a "ding", check it out!

"Those who want help should first be willing to give help."
Back to the top
 
Posted
Rating:
#92690
Avatar

You're not my slave :lol:. I remember we've discussed before, it'd be great if every user just did a little bit :).


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
There are too many online users to list.
Control functions:

Quick reply   Contract

Your name:
Your message: