portlet UI design guidelines?

[Gary Weaver]

(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 [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

[Gary Weaver]

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 [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

[Gary Thompson-4]

Some javascript/style in this post has been disabled (why?)

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" <[hidden email]>
To: [hidden email]
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. --%>
                                            &nbsp;
                                        </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 [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

-- 

You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue
 
    

[Gary Weaver]

Gary T.,

Thanks so much! That will really help and I will look into using your
example and including part of the FSS styling in our uPortal if possible
so that the portlet (in theory) might be used in both uP 3.1.1+ and uP
2.5.3.

As a note on your example usage of portlet-menu, what is especially
confusing to me about the specs related to the menu is that in JSR-286
they provided a graphical example in PLT.C of how portlet-menu-* classes
should be used which is basically about styling popout menus.

I really (!) like the portlet markup template that you wrote as well as
your example below:
http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template

Thanks!
Gary


BTW- If it helps anyone at all, seeing some of the stuff that Gary T.
wrote triggered me to fix/update my JSR-168/JSR-286 portlet styling
quick reference to just include text directly from the JSR's because
otherwise the paraphrasing I did (as well as some mistakes in
accidentally referring to/basing it on older versions of the specs and
attributing the menu classes to JSR-286 rather than JSR-168 :( !!)
probably did more harm than good :( :
http://www.scribd.com/doc/11978144/Portlet-Styling-Quick-Reference


Gary Thompson wrote:

> 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" <[hidden email]>
> To: [hidden email]
> 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 [hidden email] as:
> [hidden email]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/jasig-ue
> --
>
> You are currently subscribed to [hidden email] as: [hidden email]
> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

[Gary Weaver]

Gary T.,

Noticed that in the latest release of infusion, the class for an active
tab appears to have changed a bit from the one used in uPortal 3.1.1.

In
http://source.fluidproject.org/svn/fluid/infusion/tags/fluid-1.1.1/src/webapp/framework/fss/css/fss-layout.css

there is:
.fl-tabs .fl-tabs-active a {padding:0.25em 1.25em; border-bottom:none;
color:#000;}

and in uPortal 3.1.1 there is:
apache-tomcat-6.0.18/webapps/uPortal/media/skins/universality/common/css/fluid/fluid.layout.css

.fl-tabs .fl-activeTab {}

and (among other minified versions, etc. and in the uportal3 theme)
apache-tomcat-6.0.18/webapps/uPortal/media/skins/universality/uportal3/fluid.theme.uportal3.css

.fl-theme-uportal3 .fl-tabs li.fl-activeTab,
.fl-theme-uportal3 .fl-tabs li.fl-activeTab:hover,
.fl-theme-uportal3 .fl-tabs li.fl-activeTab a,
.fl-theme-uportal3 .fl-tabs li.fl-activeTab a:hover {background-color:
#fff; border-bottom-color:#fff; color:#508cc9;}

Some questions if you (or someone else) have time:

* Which version of Infusion does uPortal 3.1.1 use? (doesn't look like
it uses 1.1.1)
* In the FSS, is there any deprecation of CSS classnames between
versions? (I'm guessing in this case maybe this was a class that didn't
meet the naming convention so it was just changed?)
* Will uPortal deprecate the fluid CSS classnames or just go with the
flow and change classnames when FSS/Infusion changes them and people
will just need to change their skins, etc.?

Thanks!
Gary


Gary Weaver wrote:

> Gary T.,
>
> Thanks so much! That will really help and I will look into using your
> example and including part of the FSS styling in our uPortal if
> possible so that the portlet (in theory) might be used in both uP
> 3.1.1+ and uP 2.5.3.
>
> As a note on your example usage of portlet-menu, what is especially
> confusing to me about the specs related to the menu is that in JSR-286
> they provided a graphical example in PLT.C of how portlet-menu-*
> classes should be used which is basically about styling popout menus.
>
> I really (!) like the portlet markup template that you wrote as well
> as your example below:
> http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template
>
> Thanks!
> Gary
>
>
> BTW- If it helps anyone at all, seeing some of the stuff that Gary T.
> wrote triggered me to fix/update my JSR-168/JSR-286 portlet styling
> quick reference to just include text directly from the JSR's because
> otherwise the paraphrasing I did (as well as some mistakes in
> accidentally referring to/basing it on older versions of the specs and
> attributing the menu classes to JSR-286 rather than JSR-168 :( !!)
> probably did more harm than good :( :
> http://www.scribd.com/doc/11978144/Portlet-Styling-Quick-Reference
>
>
> Gary Thompson wrote:
>> 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" <[hidden email]>
>> To: [hidden email]
>> 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 [hidden email] as:
>> [hidden email]
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/jasig-ue
>> --
>>
>> You are currently subscribed to [hidden email] as:
>> [hidden email]
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

[Jacob F]

Hi Gary,
Just to answer one of your questions: indeed there is some class name deprecation in FSS and we're updating the api page (http://wiki.fluidproject.org/display/fluid/FSS+API) to reflect where things are headed.

As you've noted, ".fl-activeTab" is one such class name which is deprecated in favour of ".fl-tabs-active". We're trying to keep everyone as in the loop as possible about class name changes (they'll be outlined in our README and filed in JIRA http://issues.fluidproject.org/ ) but the documentation is still being brought up to speed.


Sorry I can't speak for the version uPortal is using or how they deprecate it...
Jacob
http://www.fluidproject.org


-----Original Message-----
From: Gary Weaver [mailto:[hidden email]]
Sent: Monday, October 19, 2009 4:28 PM
To: [hidden email]
Subject: Re: [uportal-dev] [jasig-ue] portlet UI design guidelines?

Gary T.,

Noticed that in the latest release of infusion, the class for an active
tab appears to have changed a bit from the one used in uPortal 3.1.1.

In
http://source.fluidproject.org/svn/fluid/infusion/tags/fluid-1.1.1/src/webapp/framework/fss/css/fss-layout.css

there is:
.fl-tabs .fl-tabs-active a {padding:0.25em 1.25em; border-bottom:none;
color:#000;}

and in uPortal 3.1.1 there is:
apache-tomcat-6.0.18/webapps/uPortal/media/skins/universality/common/css/fluid/fluid.layout.css

.fl-tabs .fl-activeTab {}

and (among other minified versions, etc. and in the uportal3 theme)
apache-tomcat-6.0.18/webapps/uPortal/media/skins/universality/uportal3/fluid.theme.uportal3.css

.fl-theme-uportal3 .fl-tabs li.fl-activeTab,
.fl-theme-uportal3 .fl-tabs li.fl-activeTab:hover,
.fl-theme-uportal3 .fl-tabs li.fl-activeTab a,
.fl-theme-uportal3 .fl-tabs li.fl-activeTab a:hover {background-color:
#fff; border-bottom-color:#fff; color:#508cc9;}

Some questions if you (or someone else) have time:

* Which version of Infusion does uPortal 3.1.1 use? (doesn't look like
it uses 1.1.1)
* In the FSS, is there any deprecation of CSS classnames between
versions? (I'm guessing in this case maybe this was a class that didn't
meet the naming convention so it was just changed?)
* Will uPortal deprecate the fluid CSS classnames or just go with the
flow and change classnames when FSS/Infusion changes them and people
will just need to change their skins, etc.?

Thanks!
Gary


Gary Weaver wrote:

> Gary T.,
>
> Thanks so much! That will really help and I will look into using your
> example and including part of the FSS styling in our uPortal if
> possible so that the portlet (in theory) might be used in both uP
> 3.1.1+ and uP 2.5.3.
>
> As a note on your example usage of portlet-menu, what is especially
> confusing to me about the specs related to the menu is that in JSR-286
> they provided a graphical example in PLT.C of how portlet-menu-*
> classes should be used which is basically about styling popout menus.
>
> I really (!) like the portlet markup template that you wrote as well
> as your example below:
> http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template
>
> Thanks!
> Gary
>
>
> BTW- If it helps anyone at all, seeing some of the stuff that Gary T.
> wrote triggered me to fix/update my JSR-168/JSR-286 portlet styling
> quick reference to just include text directly from the JSR's because
> otherwise the paraphrasing I did (as well as some mistakes in
> accidentally referring to/basing it on older versions of the specs and
> attributing the menu classes to JSR-286 rather than JSR-168 :( !!)
> probably did more harm than good :( :
> http://www.scribd.com/doc/11978144/Portlet-Styling-Quick-Reference
>
>
> Gary Thompson wrote:
>> 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" <[hidden email]>
>> To: [hidden email]
>> 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 [hidden email] as:
>> [hidden email]
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/jasig-ue
>> --
>>
>> You are currently subscribed to [hidden email] as:
>> [hidden email]
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
>

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue