Gary,
(Great name, BTW.)
I am glad you asked. Having standards for portlet markup and CSS is
significant in developing portlets efficiently and that result in
good user experiences.
In developing the new Portlet Administration
<http://www.ja-sig.org/wiki/display/UPC/Portlet+Administration+Portlet>
(PA) portlet user experience for uPortal via Unicon's Cooperative
Support program <http://www.unicon.net/support/cooperative>, I had
the opportunity to give some focused thought and attention to such
standards. The results of that work are built into the PA portlet
and documented (to some degree) here:
* http://www.ja-sig.org/wiki/display/UPC/User+Interface
*
http://www.ja-sig.org/wiki/display/UPC/Markup+and+CSS+Naming+Conventions
* http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template
It's not perfect, but it's a start. Please feel empowered and
encouraged to contribute to refining it.
Let me summarize a few high-level strategic thoughts and then try to
answer a few of your more specific, tactical questions around the
Mail portlet.
S1. JSR-168 CSS specification
Having many years of both broad and deep involvement in portal and
portlet user interface design and development, my assessment is that
the JSR-168 portlet CSS specification
<http://www.ja-sig.org/wiki/display/UPC/JSR-168+PLT.C+CSS+Style+Definitions>
is poorly designed, poorly defined, and woefully inadequate for
modern portlet development. It also has not been updated in many
years. This results in it being mostly useless as a standard, and
therefore not worthy of significant effort to maintain as such in the
Jasig community. For clarification, I am speaking of the CSS part of
the JSR-168 specification, not the specification as a whole. Having
concluded that it is a poor markup/CSS standard, that is not to say
that it should be totally ignored or discarded - it is indeed still
in use in uPortal and a few parts of it are usable. However, as a
community we cannot base current and future efforts on it - it is not
sufficient.
S2. Portlet user interface spans major releases of uPortal
I admire your efforts to achieve this, however I believe that you
will find this effort not worthwhile when speaking of 2.5.x and
3.1.x. Especially in regards to the user interface layer, the
differences between the two releases are rather un-spannable. Not
impossible, but probably not worth the effort. I'll demonstrate this
below in regards to your question about converting an unordered list
into tabs. My recommendation is to press forward where possible - in
most senses, uPortal and Jasig portlets are only now beginning to
achieve the user experience standards that are prevalent conventions
(and continuing to press forward) in the Web. We need not abandon
the past, but we do need to press forward - that is where most of our
energy and effort needs to be for our portal and portlets to remain
viable.
S3. As much as we are able, let's not create our own standard
We can't sustain it, and if isolated to Jasig/uPortal, that doesn't
make it much of a standard. However, I am of the opinion that Jasig
should and must set some standards in this area where other standards
are not sufficient. I am also of the opinion that where possible, we
should push those needs into other open standards, like Fluid (see
next).
S4. Fluid Skinning System
Incorporated into uPortal 3.1.x, the Fluid Skinning System
<http://wiki.fluidproject.org/x/96M7> is a CSS standard that uPortal
(and Sakai, and several newer portlets) have adopted. Fluid also has
a growing component library of many useful user interface "widgets"
like Pagers, Reorderers, and Inline Editors
<http://wiki.fluidproject.org/x/PAAF>. The Fluid Project community
<http://fluidproject.org/> is a well-balanced mix of both designers
and developers, and their processes result in friendly frameworks
that accomplish modern best practices in programming, usability, and
accessibility. As a Fluid Project community participant and member,
and hands-on user of the FSS, I can say that from personal
experience. Since the community is active and growing, the Jasig
community is welcome and encouraged to participate in the growth of
the standard, yet does not have to solely bear the burden of
maintaining the standard. My recommendation, therefore, is to
continue to standardize on Fluid and related good frameworks like
jQuery.
S5. Portability
The hallmark of the JSR-168 portlet spec is portability - the concept
that a portlet can be taken from one portal context and dropped into
wholly different portal context and operate the same. Theoretically,
it's an interesting concept, but frankly, I have never seen this work
practically. Maybe it is an easier achievement with the technology
(though my experience is that doesn't work well either), but on the
user experience front, it fails miserably. Because in user
experience, CONTEXT is critical. Let me give an example of a
singer. A singer being someone who can sing music. But a singer can
be as different as Britney Spears is from Bob Dylan is from Bob
Marley is from Mick Jagger is from Snoop Dogg is from Luciano
Pavarotti is from Elvis Presley is from Willie Nelson. If the Opera
needs a singer, you can't just unplug Snoop Dogg from rap and send
him to the Opera. He doesn't FIT. Especially when they were
expecting the Fat Lady for costuming. So like singers in different
contexts, we are trying to pass around portlets to different portal
contexts, with similar results. They don't naturally fit the new
context without a lot of re-work and makeup applied - and even then
they are easily identified as counterfeit. So far I have seen
portlet portability fall into one of two strategies. In one, the
portlet is packaged with its context (interactions, interfaces,
styling, etc.), so that it ALWAYS is an Opera singer, for example.
That works well in the Opera, but clearly fails at the rock concert.
The other strategy is to make the portlet as generic as possible.
This is the equivalent of sending a B-rate singer (has to be because
he can't focus on any one context) in his underwear to whatever gig
comes up, hoping that there will be the appropriate, fitting clothes
waiting for him. This also fails (except for maybe the rock concert,
where pretty much every singer is B-rate and in his underwear) for
pretty obvious reasons. From the user interface/user experience
perspective, portlets are particularly troubling that way. The Jasig
community is great about being open when building portlets, but that
often comes at a price of generic (B-rate, shows-up-in-his-underwear)
quality, even when placed in its own uPortal. As far as I have
experienced, this issue has yet to be solved. There isn't a good way
to package and include all of the resources - markup, CSS, images,
js, etc. - into every portlet so that it can be portable; that
defeats many other best practices, standards, and maintainability.
Howver, there is neither a good way to ensure that those resources
are available from the portal context, and in a way that the portlet
needs them to be functional and a good user experience. We have need
of solving this issue.
Now on to more tactical specifics.
T1. Portlet Administraton
The PA portlet in the 3.1 trunk is probably the best current, go
forward example. It is not perfect, but shows how an older uPortal
channel has been converted into a shiny, modern portlet. You should
also refer to this CSS file in trunk for portlet development (which
includes the JSR-168 spec and is amply commented):
\uportal-war\src\main\webapp\media\skins\universality\uportal3\uportal3_portlet.css
T2. FSS for grids and layout
FSS (included in uPortal) comes with an excellent layout/grid
framework. The FSS layout framework is being used to render the main
uPortal UI layout (multi-column and sidebars - all without tables!).
Refer to this FSS primer: http://wiki.fluidproject.org/x/-gBS
T3. Making an unordered list into tabs
On the 3.1.x release with FSS, this is simple and quick (rather
beautiful overall). Simply take your semantic unordered list markup
and sprinkle in a few FSS classes (I would also encourage some
meaningful ARIA roles for accessibility):
<div class="fl-container-flex">
<ul role="tablist" class="fl-tabs fl-tabs-left">
<li role="tab" class="fl-activeTab"><a href="#_bottom">Active
Tab</a></li>
<li role="tab"><a href="#_bottom">Tab #2</a></li>
<li role="tab"><a href="#_bottom">Tab #3</a></li>
</ul>
<div role="tabpanel" class="fl-tab-content">
Content
</div>
</div>
Viola! And you don't have to edit CSS at all. FSS layout makes
the unordered list into tabs, and FSS themes (uPortal skins) style
the tabs to match the currently selected skin.
Sadly, this will produce no tangible result in uPortal 2.5.3 - you'll
still have a basic, unordered list in the user interface. What to
do? Here's where we clearly demonstrate the shortcomings of the
JSR-168 CSS specification (I'll try not to be overly sarcastic in my
example).
CSS classes are free (or at least cheap), so in most senses, there is
no harm in layering on additional CSS classes into the markup. So
let's think about layering in JSR-168 CSS classes to support non-FSS
implementations. First, let's consult the JSR-168 spec to see what
is available. After perusal, it looks like this section makes sense:
PLT.C.6. Menus
"Menu styles define the look-and-feel of the text and background of a
menu structure. This structure may be embedded in the aggregated page
or may appear as a context sensitive popup menu."
Umm, okay, that definition makes it clear how I am supposed to use
the spec... or not. Let's see if we can make sense of the classes
they give us:
portlet-menu General menu settings such as background color,
margins, etc.
portlet-menu-item Normal, unselected menu item.
portlet-menu-item-selected Selected menu item.
portlet-menu-item-hover Normal, unselected menu item when the
mouse hovers over it.
portlet-menu-item-hover-selected Selected menu item when the
mouse hovers over it.
portlet-menu-cascade-item Normal, unselected menu item that has
submenus.
portlet-menu-cascade-item-selected Selected sub-menu item that
has sub-menus.
portlet-menu-description Descriptive text for the menu (e.g. in a
help context below the menu).
portlet-menu-caption Menu caption.
Why we need to specifically delineate "portlet-menu-item" on the <li>
(when the <li> is contained in a <ul> already specified as a
"portlet-menu") is lost on me, but okay. And we're supposed to put
in a CSS class "portlet-menu-item-hover" for mouse-hover? Isn't
there such a thing as :hover in the CSS spec itself? There's some
stuff in there that could be used (though a Menu caption? Really?
And the desciption is so helpful.), but the point is that even
something as basic as a menu is not well designed or defined in the
JSR-168 CSS spec. And note there is no JSR-168 class for the
associated tabpanel.
Taking these classes we could add in the following to our markup:
<div class="fl-container-flex">
<ul role="tablist" class="fl-tabs fl-tabs-left portlet-menu">
<li role="tab" class="fl-activeTab
portlet-menu-item-selected"><a href="#_bottom">Active Tab</a></li>
<li role="tab" class="portlet-menu-item"><a href="#_bottom">Tab
#2</a></li>
<li role="tab" class="portlet-menu-item"><a href="#_bottom">Tab
#3</a></li>
</ul>
<div role="tabpanel" class="fl-tab-content">
Content
</div>
</div>
And we would discover that this has done very little to our UI result
in 2.5.3. Still no tabs, just an unordered list with maybe a bit of
styling applied. Why? Because there is no context. What KIND of
menu is this? Nothing in the JSR-168 spec specifies this as a TAB
menu. Well, we could define that in the CSS by making all
.portlet-menu .portlet-menu-item elements inline or floated and so
forth. Super! (except that you had to figure out and test that
across browsers on your own effort, which is painful, trust me). Now
we have tabs from our unordered list. But wait - now EVERYWHERE that
these classes are used will be converted to TABS, whether they are
contextually tabs or not. The JSR-168 spec does not give us classes
to define the context.
So, okay, we could add the context to the container <div>, like so:
<div class="fl-container-flex portlet-menu-tabs">
<ul role="tablist" class="fl-tabs fl-tabs-left portlet-menu">
<li role="tab" class="fl-activeTab
portlet-menu-item-selected"><a href="#_bottom">Active Tab</a></li>
<li role="tab" class="portlet-menu-item"><a href="#_bottom">Tab
#2</a></li>
<li role="tab" class="portlet-menu-item"><a href="#_bottom">Tab
#3</a></li>
</ul>
<div role="tabpanel" class="fl-tab-content">
Content
</div>
</div>
And then solve the problem in the CSS with selectors like:
.portlet-menu-tabs .portlet-menu .portlet-menu-item {}
So that only those specifications are applied to make an unordered
list into tabs when the parent .portlet-menu-tabs class is present.
However, now we have broken the standard. No one will get the
benefit of using these classes to achieve tabs from an unordered list
without knowing to put the .portlet-menu-tabs class on the containing
element. And even if that class is on the containing element, if you
take the portlet out of uPortal and try to use it elsewhere, it will
revert to an undesireable, plain unordered list. You could say the
same about FSS (that it isn't portable), but it IS easily includable
and relieves us from having to solve the problem, test the solution,
and maintain the standard.
My recommendation: include FSS into your CSS includes in your 2.5.3
skin (minimally fss-layout.css), and you will at least get the basic
structural benefits without doing any extra work and without
complicating the markup with the JSR-168 classes. Besides, after
including the JSR-168 classes, if you were to stumble on this markup,
which classes do you use/modify? The FSS ones, or the JSR-168 ones?
And if they are both (FSS and JSR-168) trying to make tabs out of an
unordered list, you are going to get some ugly CSS conflicts. I like
to Keep It Simple. The FSS markup is much cleaner, and does the job
much better, with little effort required on your part as the
implementor.
Hope that helps. I welcome more discussion on these matters.
Gary Thompson
User Experience Leader
Unicon | www.unicon.net
----- Original Message -----
From: "Gary Weaver" <gary.wea...@duke.edu>
To: jasig...@lists.ja-sig.org
Sent: Thursday, October 15, 2009 10:51:42 AM GMT -07:00 U.S. Mountain
Time (Arizona)
Subject: Re:[jasig-ue] portlet UI design guidelines?
I should probably clarify that in the MailPortlet when you click on a
tab, that it when it queries the pop3/imap server for mail, so I'm not
looking for a show/hide div type of thing, but rather either the
standard CSS classes that display line-items horizontally (in a way
friendly to various existing skins in both uPortal 2.5.3 and uPortal
3.1.1) or something (that I'm not guessing would be a simple?) that not
only display tabs but would use Ajax to load the chosen tab in the
background and to do this in a skin-friendly way (specifically in the
formatting of the tabs) that hopefully could work without much problem
in both uPortal 2.5.3 and 3.1.1. The following is basically what I'm
showing for tabs atop the mail message list table (I made up the class
names to show what I'm looking for):
<ul
class="some-well-used-skin-class-to-indicate-these-are-tabs-and-therefore-this-unordered-list-should-be-composed-of-blocked-bordered-and-backgrounded-inline-line-items">
<li>...</li>
<li
class="some-well-used-skin-class-to-indicate-this-inline-line-item-tab-is-selected">...</li>
<li>...</li>
</ul>
It looks like maybe the thing to use in uPortal 3.1.1 is fl-tabs as the
class name and fl-activeTab for the selected tab. But can I just define
those in the portlet's CSS so that it works in older versions without it
overriding the newer stuff in uPortal 3.1.1?
And for table formatting, I was just checking to see what the best way
to define the table and its classes are or what you would say is a
uPortal 2.5.3 and 3.1.1 friendly way to define a table in a portlet. I
currently have the following for the display of mail messages, but I'm
guessing I could do better?:
<%-- is there any nice column-resizing
javascript deal available via uP 3.1 and if so could we include that in
the portlet so that it could be used in both earlier and later versions
of uPortal? %-->
<table
class="is-there-some-sort-of-standard-uportal-skin-class-that-should-be-used-here-that-might-add-a-border-or-similar">
<tbody>
<c:forEach
items="${selectedMailAccountDetails.stubs}" var="stub"
varStatus="counter">
<c:set var="className">${ (counter.index
% 2 == 0) ? 'portlet-section-body' : 'portlet-section-alternate'}
${stub.seen ? 'mailportlet-read-message' :
'mailportlet-unread-message'}</c:set>
<tr class="${className}">
<td>
<c:if test="${stub.flagged}">
<%-- am guessing maybe there
are famfamfam icons for these, but then should resource-server be a
requirement since it serves those in 3.1 or should they be included in
the portlet to be compatible with older uPortal versions? --%>
<img
src="<%=request.getContextPath()%>/images/star.png"/>
</c:if>
<c:if test="${stub.answered}">
<img
src="<%=request.getContextPath()%>/images/answered.png"/>
</c:if>
<c:if test="${not stub.flagged
&& not stub.answered}">
<%-- it just looks bad when
there are no flags on any messages. assuming this column have some sort
of minimum width. --%>
</c:if>
</td>
<td><span class=${stub.deleted ?
'mailportlet-deleted-message' : ''}>
<a
href="${selectedMailAccountDetails.link}"><c:choose><c:when
test="${empty stub.from}"><fmt:message
key="noSender"/></c:when><c:otherwise><c:out
value="${stub.from}"/></c:otherwise></c:choose></a></span></td>
<td><span class=${stub.deleted ?
'mailportlet-deleted-message' : ''}><a
href="${selectedMailAccountDetails.link}"><c:choose><c:when
test="${empty stub.subject}"><fmt:message
key="noSubject"/></c:when><c:otherwise><c:out
value="${stub.subject}"/></c:otherwise></c:choose></a></span></td>
<td><span class=${stub.deleted ?
'mailportlet-deleted-message' : ''}><a
href="${selectedMailAccountDetails.link}"><c:choose><c:when
test="${empty stub.received}"><fmt:message
key="noDate"/></c:when><c:otherwise><c:out
value="${stub.received}"/></c:otherwise></c:choose></a></span></td>
</tr>
</c:forEach>
</tbody>
</table>
Thanks,
Gary
Gary Weaver wrote:
> (sorry to cross-post, but I don't know where to send this)
>
> Am having a little bit of a dilemma working on the MailPortlet UI and
> thought maybe someone could provide some guidance.
>
> * I want to use what I can of what standards I should from PLT.C CSS
> classes of JSR-168, and am trying to make it utilize the classes as
> defined in the default skin of uPortal 3.1.1 for reference
> (skins/universality/uportal3/jsr168_portlet_spec.css) just to have a
> better feel for what it would look like in the future if we were to
> upgrade uPortal 3.1+. I know that these classes were also defined in
> uPortal 2.5.3 skins, but I haven't looked at how those would look yet.
>
> * Those classes in the default skin of uP 3.1.1 at least seem to just
> define background color, border color, change a few font sizes/bold a
> few things, and do some light padding/margin changes.
>
> * Things like portlet-section-header, portlet-section-subheader, and
> portlet-form-label aren't defining "display: block;" and therefore
> also not defining margins/padding, so I'm unclear as to whether those
> should be headers (h3, h4, ...) or label elements (all seem like they
> should be headers I guess).
>
> * I need other CSS classes to make nice (list item) tabs across the
> top of the main MailPortlet view
>
> * I need other CSS classes to do some better formatting of the table
> containing the list of the most recent email messages for a specific
> account (which has columns for flags, sender, subject, and date like
> you'd expect in the main message list view a mail client)
>
> * It would be great (but not totally necessary) to have resizeable
> columns in the table (so some standard javascript to assist with that
> might be nice) or at the very least to have it defined the table
>
> My questions are:
>
> * Were there CSS classes that did that in the standard skins that came
> with uPortal 2.5.3 (I'm looking through them now- not sure)? Do those
> still apply for uP 3.1.1?
>
> * Could you point me at specific examples of portlets or other places
> in uPortal 3.1.1 that do a good job (list item) tabs and grid/table
> formatting like I'm talking about in a uPortal-skin friendly way?
>
> * What level of header should portlet-section-header,
> portlet-section-subheader, and portlet-form-label be to have
> consistency throughout portlets and if they should be labels, what
> additional classes should be used if any to define that they should be
> display:block and to define their margins/padding?
>
> * Do you think that ResourceServer should be a requirement for
> portlets to display correctly from here on out, and if so, do you know
> of anyone using it with older versions of uPortal?
>
> I completely understand that at some point the past has to be left
> behind and newer portlets should only work with uPortal 3.1+, but for
> those of us that want to contribute in such a way that portlets can be
> used in both uPortal 3.1.1+ and uPortal 2.5.3, I want to make sure
> that I'm defining things correctly and defining portlet-specific CSS
> and/or reusing skin CSS in a way that is kosher for both environments
> (at least for now, if it makes sense).
>
> Thanks!
>
> Gary
>
--
You are currently subscribed to jasig...@lists.ja-sig.org as:
g...@unicon.net
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/jasig-ue
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
gary.wea...@duke.edu
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
