Forum OpenACS Development: Response to Portals roadmap proposal

However, I'm not really clear about how portals, CMS and
graphic designers work together. It seems to me that portals is a
way of removing the graphic designer from having to generate UI
all the time and allowing the user to to select a modular
presentation of data from across the system. Rather than have
the UI designer define how and where each person can view
information, the user can select what info and how they wills see
it.

To begin with, CMS and portals don't necessarily work
together at all. In fact, my point was exactly that CMS and portals
are largely orthogonal. CMS is fine if you want to crank out huge
numbers of content pages but not necessarily helpful when you
want to create a relatively small number of site pages with
hooks into various ACS modules. This is exactly why we need a
robust portals module in addition to a CMS.

Regarding the question of whether the whole point of the
portals module is to get rid of the graphic designers, I'd say the
answer is "not necessarily." Certainly, one possible use of
portals is to allow end users to pick their own personal windows
into a site. However, more often portals (if built right) could allow
site designers to set up the look and feel for whole classes of
users. If you think about the layout of, say, the home page of a
site, a great deal of thought goes into the visual design. Sure,
you may have an area (or "portlet") with links to latest news and
another with links to discussion boards, but they are not all
equally weighted. You want to be able to call the users' attention
to whatever is most important. If all portlets look exactly the
same, then you (the site designer) are denied the ability to
emphasize or de-emphasize elements on the page relative to
each other.

Perhaps my real question is what kind of control do you
want or need over the portlets?

Think of the portals module as a site layout tool--a sort of
Quark for OpenACS. With it, you could bundle up any chunk of a
page (e.g., a box of text, a graphic, a news items window) as an
object and move it around a page, move it between pages, and
so on. In this vision, you'd want to exert the same visual control
over a portlet that you'd want to have over any object on any web
page.

Shouldn't the portlets have as little UI design as possible
so that they can conform to any data placed in them?

I'm not exactly sure what you mean by having a portlet
"conform to any data" placed in it. I agree that the portlets (by
which I mean the containers for the data) should have very
little UI. However, the portlet instances (by which I mean the data
showing through the container, displayed in a particular way)
are user interface. As such, a designer should be able to
control the way they look (and, in some cases, act).

What does a portlet consist of, anyway?

Maybe the best way to think of a portlet is as a container for a
(static or dynamic) content object. It can be displayed as part or
all of a page. Why turn pages or page parts into objects? Mainly
so that you can move it around easily (i.e., without
programming). Again, it's a layout tool.

Can you give me some examples of what kinds of data
would be displayed in each of these?

Sure. I'll use the example of an online course, since I know
that development problem the best:
<ul>
<li>You want to create a page tied to the calendar package that
shows due dates for all assignments (i.e., a syllabus). But you're
not sure where you want to put that page on the menu bar. So
you package it up as a portlet so you can move it around
easily.</li>
<li>You want to create a window that shows new posts to the
discussion board. You want it on the home page and you want it
to have medium importance. So you put it in a portlet, move it to
the upper right quadrant of the page, and give it a visual
treatment that adds some weight.</li>
<li>You also want to create a window on the home page that
randomly displayed highly rated discussion posts. You want that
to be very prominent. So you put it in the upper left-hand
quandrant and you make it really stand out.</li>
<li>Even though about 90% of your class home page is dynamic,
you do want to have a static "Welcome to the class" message.
So create a portlet with an invisible box around it and move it to
the top of the page, spanning all three columns.</li>
</ul>
Could this be done without portlets? Sure. But you'd need a
programmer or at least an adp-savvy web designer to do it some
other way. With portlets, you can have each teacher
customize her own class without the help of a programmer. You
can also allow those teachers with a little graphic design savvy
or graphic design help (but without a programmer) to customize
the look of the objects on the page to give each object the
appropriate visual weight and position for UI (and aesthetic)
purposes.

Forgive me for asking these questions if they are a little
elementary.

Not at all. Don and I are proposing a new way of thinking
about the portals module. Nothing is self-evident here.