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 (PA) portlet user experience for
uPortal via Unicon's Cooperative Support program , 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 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 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 . The Fluid Project community 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:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
