Skip to end of metadata
Go to start of metadata

New Concept

This is an idea for discussion, please feel free to edit, comment, etc.


This describes an idea to allow more flexible use of the portal by tool writers and services in Sakai. This is meant to replace the things that are effectively hardcoded into the portal with more flexible zones which can have content placed into them. This will allow for more flexible control over the portal and the ability to added more interesting data and UI pieces within the portal itself.


  • Current issues that this addresses
    • Portal layout is relatively inflexible and in some cases hardcoded, tools are stuck in frame-bound silos
  • Goals
    • More flexible presentation options for tools and services
    • Allow developers to easily extend the portal to add widgets, controls, etc. to various hotspots in the portal called active zones
    • Allows for control of the location of the active zones using CSS
    • Uses a very simple provider style methodology to add extra data to an active zone (tool developer does not have to make changes to the portal code)
    • Allows for appending of multiple html fragments from multiple sources in a single zone (or replacing/clearing zone content)
  • Benefits
    • Impact on UX and teaching and learning benefit: promotes better UI and more options for innovation, so both positive
    • More flexible portal and more dynamic tools, more customization for local institutions without branching code
    • Easy solution to the issue: Fairly simple patch to the existing portal code to allow this to work (quick solution)
    • Reduce dependencies of portal on other projects

Portal Active Zones

  • Mockup showing the zones (just to give a general idea of their locations)
    • Zones can be resized and tweaked via CSS
    • Initially the Special Zones will be populated with default data
    • Open Zones can have as many html fragments added to them as is desired
    • Sample HTML for a zone
      <div class="activezone">
        <ul class="activezonelist">
          <li class="activezonelistitem">
            An HTML fragment with a <a href="">link to university email</a>
          <li class="activezonelistitem">
            <form target="something.html">
              <input type="submit" value="Revert user to aaronz" />
    • NOTE Unused zones would simply not be rendered (i.e. they would not take up room on the screen)
  • How would it work?
    • Developers would implement an interface which returns a String or a Stream or something which is an html fragement (this may also support portlets)
      • The interface would include mentioning the zone key (e.g. HeaderTop) which the html fragment is inserted into
    • The portal will ask for all the zone contributors to provide it with content when it renders
    • The content would be inserted into an html list in the zone which will be a div or whatever the UX team deems appropriate
      • This would allow as many html fragments to be inserted as are desired for a single zone without overwriting current data
      • Example: In Zone HeaderTop, Tool A puts in an html fragment with a form and submit button, Tool B puts in a fragment with some html and javascript, the portal would put each fragment into the html list in HeaderTop such that both fragments are rendered in the list
  • Some sample uses of active zones
    • Presence could be handled via an active zone instead of requiring hard coding in the portal
    • Become User could place a button in one of the header zones which allows the user to switch back to their original account
    • Search could be optionally placed into the header
    • Tools could suppress the menu bar or other parts of the portal if desired
  • Active Zones Implementation Ideas - some possible ways to implement this idea in the portal
  • No labels


  1. I like this technical approach. It's clean and opens up the possibility for simple cross-cutting interfaces to be hosted within the portal. Nice work, Aaron!

    A couple of points from a functional perspective:

    The risk with this approach is that, if used unwisely, we may add significant extra clutter to the interface. How do tool developers know how these new zones should be used? How do we avoid an influx of complex, attention-grabbing data being displayed using this technique?

    Perhaps it's as simple as prescribing the scenarios in which tool developers should surface information in these zones. Careful design may determine what we actually need here. The challenge, of course, is having the community usage from the whole perspective, not just from the perspective of a particular tool's needs.

    I'd like to see some more concrete examples of exactly how we'd like to use this type of functionality. The example of placing Search within the header is a very compelling one, but are there other specific examples of what would be placed into these zones?

    I like this approach a lot.

  2. I also like the idea and am glad to see some facility for building ubiquitous widgets in the portal. I visited this page as a result of a "omnipresent chat" feature proposed on the list. In that case it may be that there is no need for the "chat" tool diplayed in the portal "zone" to be aware of anything that is going on with the active tool for that user.

    However, there are some things that would really benefit from being aware of context. A tagging interface that popped up in one of these zones would need to know what it was referring to. Is this an assignment? a file? a discussion thread?

    1. Figuring out which context you are operating in should be no problem working with a portal zone. You would have access to everything you normally do in your tool.

  3. As a tool developer moonlighting as a skin developer (or was it the other way around?) this is precisely what I'd like to see hapening in Sakai. Also, it is an approach that's familiar to developers of PHP content/community management systems such as Drupal ( or Xoops (

    I would suggest to use a three column layout for the content area too. That is consistent with the header and footer and would allow developers to place the menu at the right side of the screen or leave the menu at the left side but put some widgets at the right.

    1. Menu position is controlled by CSS but we could add in zones for the right hand size.

  4. Is the idea/concept on this page still actively being pursued, or has it been superseded by other activities or needs?