What's a MetaPage™?   

What's a Micro-Agreement™?   

• Micro-Agreements™ are the small gestures of mutual accountability that tie us together as a high-performance team.
• The Demand! Management platform is a system for building secure Web applications that facilitate mutual accountability.   
• At present, its primary uses are in support of high-tech project management and the workflow related to medical billing, where patients' medical information must be shared in compliance with Federal HIPAA requirements for electronic document sharing.
• The workflow facilitation features worthy of mention in this quick summary include these:
• New Member Invitations -- Members can invite new members to participate in their organization or project.  The prospective member receives an e-mail notification with a link to the intake processing page.
• Request for Commitment -- You can assign a task to another member.  The system sends an e-mail notification requesting that they commit to owning responsibility for completing the task.
• Commitment Acceptance Notifications -- When a member commits to owning responsibility for a task, the system notifies the person who sent the Request for Commitment (and, of course, the person who agreed).
• Auto-nagging -- The system can send a periodic reminder that you haven't yet accepted or declined a Request for Commitment for a task assigned to you.
• Request for a Status Update

For more information about the Demand! Management™ platform, visit this page.

MetaPage™ is a simple, innovative architecture
in the Micro-Agreements platform for Web applications.

Recently introduced in the Micro-Agreements platform, the MetaPage architecture enables a designer to build a page from simple, reusable HTML+CSS components -- e.g., a filtered list of tasks or a set of control buttons.  Each of these components is a MetaPage.   Each Web page built on the MetaPages architecture starts with a host MetaPage that contains its component MetaPages.  Each MetaPage is smart enough to pull a data set from the database but without the designer needing to know anything about Structured Query Language (SQL) or ADO data access commands.  

Here's a screenshot of the Dashboard MetaPage for the Micro-Agreements™ platform:

(from http://whaleprojects.com/members/MetaPage.asp?MetaPageID=Dashboard)

Note these features of the Dashboard MetaPage:

1. It's composed from several reusable page parts, each of which is a MetaPage:
• My Immediate Responsibilities lists the tasks assigned to me for which I haven't yet responded to a Request for Commitment e-mail notification.
• My Task Hotlist lists the tasks I've identified that I want to always appear on my hotlist until I mark them as complete or no longer hotlisted.  To view the list, I click on the plus sign to expand the list.
• The list of my incomplete tasks is also collapsed.  To see the list and view each task individually, I can click the plus sign to expand the list and click on a specific task to work on it.
2. MetaPages can be nested -- that is, you can include mutiple component ("child") MetaPages within a host ("parent") MetaPage.
3. As long as the developer doesn't apply in-line styling while building the layout of the pages, each MetaPage can easily be styled by a designer using their favorite development environment for working with CSS files, independently from the methods used by the developer.

Improved Collaboration During Development

The MetaPage approach makes it easier to split the styling in cascading stylesheets (CSS) from the structural elements in HTML -- a longtime goal I've had -- so while while the designer(s) work(s) independently on the presentation layer using HTML and CSS to craft a pleasant user experience, the technical developer can work on the data model and the logic of the application.  Integrating the data elements into the presentation layer is now dirt simple.  

And multiple designers can work independently on a site without stepping on each other's layouts.  

Here's how it works:  In the beginning of the project, the participants agree on the <DIV> IDs for the overall structure of each page, and they agree on the names for the CSS classes to be used.  

Their agreement is represented by ...

1. an HTML MetaPage template   (Here's an example)
2. a site-wide CSS file
3. a page-specific CSS file for each page (the "parent" MetaPage)
   or sub-page (a "child" MetaPage)

The Micro-Agreements implementation of MetaPages is an effective rapid-prototyping approach in agile development -- and a much more effective model for collaboration between technical developers and Web designers!  Project methodology support tools in the Micro-Agreements platform have been used and refined by Web developers for over 10 years.

MetaPages deliver a simple content management system.  You can manage much of the content in the application's database, supported by the simple workflow and project management functionality of the Micro-Agreements platform.  The presentation structure for the content can be maintained separately from the content.

MetaPage.asp?MetaPageID=Quotations is a server page (the MetaPage processor) that reads the HTML "template" from tblMetaPage in the database, either as stored text or from a file (like MetaPage_Quotations.htm), the path to which is identified in the page metadata.  

Here's the text form of a MetaPage template for a page that displays quotations from the table tblQuotation --> http://whaleprojects.com/members/MetaPageTemplate_Quotations.txt.  

Note how references to data fields from the data source (which would be specified by the developer) are encoded -- e.g., %strMetaPage_PageTitle% would tell the MetaPage processor to substitute the page title from the page metadata.  

Note that %row_start% and %row_end% delimit the HTML that's to be repeated for each row in the recordset specified by the SQL query identified in the page metadata.  So %memQuotation% between %row_start% and %row_end% tells the MetaPage processor to substitute the value in the field "memQuotation" for the reference %memQuotation% in the MetaPage template, once for each row in the recordset for the MetaPage.

Here's an example that reads the Metapage template, substitutes the data, and applies the site-specific and page-specific CSS files --> http://whaleprojects.com/members/MetaPage.asp?strMetaPageID=Quotations

Here's the page-specific CSS --> http://whaleprojects.com/members/CSS/Quotations.css

Notice how I handle iteration through rows in the associated recordset, specified by a SQL query in the page metadata (in tblMetaPage).   %row_start% delimits the beginning of the HTML which will be replicated to display each row in the SQL-specified recordset.  %row_end% delimits the end of the HTML to iterate for each row.

This might require a shared-desktop runthrough to make any sense, depending on how facile you are with building Web pages. 

The approach may fall down when you need logic within the row.  I'll hit that kind of limitation as I begin to adopt this approach for production pages.  Yesterday, I completed implementation of the first production page to adopt this architecture.  Now, the system is tracking changes on most of the fields in the Task table.  When you click on the link, Show a log of changes, on the Task_AddChange.asp page (or on the Task List), it displays the change log for that task.  The change log display is architected as a metapage.

As I build new features into the Demand! Management Platform, I intend to adopt this architecture as much as possible, which will force me to make it more adaptable in applying the prototyping principles where designers and developers can work separately and avoid stepping on each other's work.

As an example, I needed a list of the MetaPages I've built in tblMetaPage.  After scratching my head about how to code a page to list the rows in that table (which usually takes me at least half a day), I slapped my forehead, then built a metapage that lists the metapages (in about 7 minutes) --> http://whaleprojects.com/members/MetaPage.asp?MetaPageID=_MetaPages

And it's JUST ... that simple!  ;-)