Bagus.org does all that. It is a "web publishing application" where you can keep your content, navigation and interface elements separately in a database and let the Java backend put it all together. If you are new to Web site construction, you'll find bagus.org introduces you to many important concepts that will go a long way to helping you master basic Internet publishing skills. If you have been working on the Web for years, you'll find that bagus.org organizes your projects in a way that saves you lots of time and energy.
Unlike many applications that seem to hide the way they work from the users of it, bagus.org is definitely easier to understand if you really understand how it works. There are actually five separate database tables that collect data on bagus.org. There's the editors table, the content storage table, the content pointer table, the navigation information table, and the page interface table. Each holds their particular type of information and interacts with the others to put the content an editor wants on a linked set of pages with navigation and the content that you want. Here's a little more information on what each table holds.
- The Content table, otherwise known as the "contentbase" table, holds information in fields such as the title of the content and who wrote it. There are other fields such as a description, the content itself, dates, who entered it and more.
- The content pointer table, otherwise known as the "meta" table, holds the information that tells the system what page to display the content on and whether the content should be live or if it is still in the editing workflow. I'll get into how to create new pages and point your content so it will appear on them in a little bit.
- The navigation table, otherwise known as the "pulldowns" table controlls the name and appearance of navigation elements. Navigation is used to link down to lower level pages and then of course, back up to top level pages. The pulldowns table is where you'd store the image tags for things like mouseover images. You can see on the Survivors Wall demo that the links to things like "Join The Wall" and "Browse The Wall" are in this case done with text links. The text of these links is stored in the pulldowns table.
- The page configuration table, otherwise known as the matrix holds page layout information such as how many columns your page has, what's in each of the columns, what graphics are being used for the pages' interface and more. It also has information on which elements of the contentbase table should be in the forms that allow users to add new content to the site and on which elements of the contentbase table should displayed for that page. You can collect one type of information while displaying another. The matrix table also holds a place for "Cascading Style Sheet" information. Bagus.org uses Style sheets extensively and editors will want to learn this awesome technology. They are the Web standard way of separating text from the appearance of text and handling the backgrounds, margins and borders of any HTML table cell.
- Finally, the editors table, otherwise known as the editors table, has information on who has control to the various parts of the editing and site management tools. An super-user editor for a given project can create new editors that have control over any of the database tables mentioned here for limited branches of the project
The one page site is now viewable, but not very exciting. It will have the name of your project as a "section title" and have a form that says, "Please Add Something". And adding something is just the way to get projects underway.
Web projects often need some prior planning. One should brainstorm requirements for the site, consider how the information will be organized in a flow chart of pages, come up with a design scheme with headers, footers and maybe even graphical navigation buttons and finally have some information that you want to have people see. The more of this type of planning you do, the better your site usually becomes. However, bagus.org allows project managers to get started with just content. As a manager gets used to using the tools, they'll learn simple ways to enhance and customize the appearance of their project using Internet standard stuff like html and style sheets. You can as suggested above, give out separate permissions to a copy editor, a designer and a producer so that the next steps can all be done by the right people.
After a piece of content is added to the first page, a project manager can rejoice and read their content, add more content or go to the editing tool. As mentioned above, there are two files for each project. The first is the front end, and the second is the back end or editors tool.
Project managers are given a user name and password to their back end tools. Once they log in, they'll see a greeting and four separate html tables that provide access to the information that has been stored in the database tables for their project. The first table holds links to where the project manager could edit the initial submission (contentbase) or change what page the content should be on (meta). The second table is the page configuration table. At first, there's only one page created. All the settings for the project home page are accessed by clicking on the "ID" link in the page configuration table. The third table is for control of navigation elements. The fourth table allows managers to add new editors and make it so in their editing tool, the new editors only see some of the tables we just talked about.
When a project manager clicks on the link to edit the content in their editing tool, they get to a page with a form with all of the elements of the piece of content such as the title, description and content where they can edit them. There's a button to click to save their work and return them to the master editing tool page. The same is with editing any of the other areas on the master editing page. One click to get to the page where you change settings and pressing save to get back to the master tool page.
Further instructions for how to use each of the five types of management tools to customize projects are in the tools themselves and in the official (unfinished) "Managers Guide". However a little more information might be helpful here.
Web projects often have a heirarchy of information. Much as a computer has the root directory, folders and subfolders, web sites have home pages, top level pages, 2nd level pages and third level pages. A typical brochure ware type site would have top level links like "About Us", "Products," Services," and "Jobs". The "About Us" area might have second level pages like "Contact" and "Press Releases". The "Jobs" area might have second level pages linked to it for "Marketing", "Sales", Engineering", etc. The Engineering jobs could be further broken down into pages like "Networking", "Desktop Support", and "Programming". Bagus.org allows you to have any number of top level pages, each with any number of second level pages under them and each of those with as many third level pages as you want. Most structured Web sites don't get deeper than that because it requires too much clicking for anyone to find the information.
The letters x, y, and z are used as variables on bagus.org to correspond to top, second and third level navigation. In the example above, "About Us", "Products", "Services", and "Jobs" are this projects' x's. "Contact", "Press Releases", "Engineering", "Marketing" are all this projects' y's. The "Engineering Jobs" page is a page where x=jobs and y=engineering. Finally the "Programming" page is a z page with y=Engineering and x=Jobs.
On the page for editing the pointers to content, which again is accessed thru the master editing tool, underneath the area where you select which pages a piece of content should be on, there's a strange little triangle interface that allows you to "bubble up" content from lower level pages to higher level pages. In our brochure site project, one could imagine that a project manager might want the main "Jobs" page to display some of the best jobs as well as link to the sub-categories of jobs. So a piece of content can be seen in more than one place if the triangle interface is managed correctly. Content always appears on the deepest page on the project it is assigned to. So for instance, the "programming" jobs would always appear on the "xyz" page, but if one clicked the "xyPage" button, it would also appear on the "Jobs-Engineering" page. If one clicked the "xPage" button, it would also appear on the main "Jobs" page. If one clicked the button in the middle of the triangle, it would appear on the project home page as well. You need to be careful, because if you clicked "zPage" on the triange interface for a programmer job, you in essence would be creating a new Top level "Programming" page that would be linked to on the home page. The idea is that you can have three sets of top level pages, each with their own sub pages and third level pages. That might be useful for some very complex web projects, but for now since control over where the navigation appears is limited, it probably should just be avoided by never clicking the "zPage" or "yPage" buttons in the triangle. Stick to having x be the top, y be second and z be third.
One other note is that in order for a page to be linked to, it must have some live content assigned to it. So using our example, if all your jobs were categorized down to the third level, and nothing was pointed to appear on the engineering page, the "Engineering" page would never be linked to from the main "Jobs" page. If you really need to have a page with no live content on it, one trick is to put a piece of content on it and then turn all the content display attributes off for that page in the page configuration tool.
Speaking of the page configuration tool, as you move content to new pages as described above, links to more pages will appear in the "Configure Pages" table in the master editing tool. After clicking on the link to configure a page, you'll see a outline of a page that has links in it that take you to the part of the form that allows you to configure it. Examples are the "head" where you put html that you would want in the head of your pages such as meta keywords, style tags and javascript. Another example is the Left Column. Here, if you provide a width in pixels for your left column, you can enter html that will appear in the left column. There are actually three parts to the columns: top, tools and bottom. The reason for this is that you can share elements of pages with other pages. So you could perhaps want to share the top of a left column on every page in your site while leaving the bottom for more page specific material. The "tools" in the middle for now just means that at the click of a button in the page configuration tool, you can have a search form added to your column.
By default, interface elements such as the "head" and "left column top" added to the home page configuration are shared by all lower level pages. So you can enter your style tag in one place and have it shared everywhere. Like "server side includes" in flat file web sites, it might be described as cascading html since a global configuration is used unless more local configurations are available. This saves you from having to manage code in more than one place.
While many interface areas such as "bodyTop" and "BodyBottom" use this cascading html technique, others are unique for each page. Things like which elements of the form should be displayed to allow for content addition is handled separately on every page. The width for your page, the column widths, and whether the addition form is displayed at all are also controlled individually for each page. However, there is one more link on the master editing tool page called "SuperConfig" that allows you to change some of these settings for all of your pages at once.
It's useful to know how the urls for the pages are formed. The goal was to make it so every page and every piece of content could have a url that you could copy and mail to someone so they could get directly to the page you wanted them to see. I'll use the Survivors Wall example to explain. Again, projects can have up to three levels of pages below the home page. For the Survivors Wall, the home page url looks like this: http://www.bagus.org/survivorswall/. The top level "Browse the Wall" page's url looks like this: http://www.bagus.org/survivorswall/index.jsp?x=Browse_The_Wall. The second level "Breast Cancer" page's url looks like this: http://www.bagus.org/survivorswall/index.jsp?x=Browse_The_Wall&y=Breast_Cancer&f=x. Note the &f=x on the bottom. That allows the system to know that the "Browse the Wall" page is the top level page and so the "Breast Cancer" is the second level page. If there were a third level below the Breast Cancer page, the url might look something like this: http://www.bagus.org/survivorswall/index.jsp?x=Browse_The_Wall&y=Breast_Cancer&z=Ductal_Carcinoma&f=x&s=y. Note how the names of the pages are in the url. That brings us to how you might change the name for a page and add a graphic link to it.
By default, links to lower level pages are text links. Of course you have control over their color, font face and size in the style sheet. To change the name itself, you would want to do it in a way that all the content that was supposed to be on that page gets updated to appear on a page with the new name. You can change names like that in the by using the links in the navigation table on the master editing tool. The Navigation table is devided into lists of x's, y's, and z's. Using our Brochure site example, you could click directly on the word "Jobs" and on the page that follows, select "Change Name" and then enter something like "Employment Opportunities". Pressing save then changes the name of the page and changes all the links to it. Note that while you can enter spaces in names for pages, the spaces get converted underscores for use in the url. The name Employment Opportunities would become associated with an x=Employment_Opportunities.
There's a little bit more to the navigation tool. If you "change the name" to a name that already exists, you won't be adding any new pages, you'll just be deleting the one you had and moving all the content pointers to the pre existing page. It's useful for merging content from multiple areas onto one page.
You can also use the Navigation tools to delete pages. When you do that, all the content that was assigned to them gets a status of "Archived" so it won't get displayed, but it will still be searchable.
You can also add new pages with this tool, but since there wouldn't be any content on them to start, you'd later have to go and point some content on to the new page in order for that page to appear on your live site and in the editing tools. When you do add new x's, y's or z's through either the Navigation tools or the Content Pointer tools, what actually happens is that it makes a page for every possible combination of your existing x's, y's and z's. Many you'll never use, but they're there anyway. For example, in our brochure site example, the x=Products&y=Press_Releases&f=y page actually exists in the page configuration database. If you never put live content on it, it will never be linked to.
Finally, the Navigation tools have a place where you can add an image tag so that you have a graphical link instead of the text link. There are three separate images you can have for each x, y and z. The first is the main image that you want people to see. The second is the image you want them to see if they are actually on the page. So the "About Us" image may have one look on the home page, but a separate look on the "About Us" page itself. The third image is a mouseover image. That's the image people will see if they roll the mouse over the navigation element. Mouseover code is handled for you automatically, so just put the right image tags in place and it'll work automatically.
Finally, the question that I get asked all the time is how to get images up on to the server. There is no image upload feature to bagus.org. Project managers can either ask me for an account where they can ftp images to the server or they can host the images on another server. The reason for this is that handling image uploads over the web is actually very complicated and the bagus.org server itself currently does not have that much disk space.