Re: [uportal-dev] Nominations open: uPortal Steering Committee Vacancy
+1 for Drew Wills. He's not only a skilled developer, but has a passion for uPortal and the community. -Gary On Dec 18, 2012, at 1:20 PM, Carroll, Tim wrote: I'd like to nominate Drew Wills. He is a long standing member of the uPortal and broader Jasig community. He is very active on list, at conferences, and within adopting institutions. His work is both well known and well done. Bottom line, he is a great person to work with, talk to, and learn from... -Original Message- From: Jim Helwig jim.hel...@doit.wisc.edu Reply-To: uportal-dev@lists.ja-sig.org uportal-dev@lists.ja-sig.org Date: Tuesday, December 18, 2012 12:55 PM To: uportal-dev@lists.ja-sig.org uportal-dev@lists.ja-sig.org Subject: [uportal-dev] Nominations open: uPortal Steering Committee Vacancy The uPortal Steering Committee has been extremely grateful for all the hard work Jen has put in over the years and we wish her the best of luck in her new endeavors. That does leave us with a developer representative vacancy on the committee. Any uPortal developer with current commit access is eligible to be nominated (by others or by themselves). Please send your nomination (with any supporting rationale) on-list by end of day Friday, December 21, 2012. Thank you, Jim Helwig uPortal Steering Committee Chair -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: tcarr...@illinois.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: g...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Fragment Editor UI
Fantastic. Generally, I think any time you can do something without having to write XML, it's a win. -Gary On May 18, 2012, at 9:56 AM, Peter Hart wrote: What if we lived in a day where an administrator could create, edit or remove fragments in uPortal4 without writing a single line of XML? That day may be upon us, and this is what it might look like: https://wiki.jasig.org/display/UPC/uPortal+4+DLM+Fragment+Manager+Interface Peter J. Hart User Experience unicon.net -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: g...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] sass-maven-plugin
Eric,
Yay! Thanks for completing that work. I agree that it should be merged into
master and add the documentation you listed. I can contribute to #1-4. I also
agree that it feels like a 4.1 change.
Just so that everyone is aware, SCSS will accept any valid CSS syntax. So if
people want to still author in CSS, it can be added to the SCSS files. This is
true for both uPortal development as well as institution custom skins. Ideally,
people would uptake the benefits of SCSS, but plain CSS is still valid within
SCSS.
-Gary
On Apr 30, 2012, at 2:34 PM, Eric Dalquist wrote:
Luckily the resource aggregation plugin required no work and we have the
build time SCSS - CSS compilation working in the UP-3456 branch.
I'm thinking we should get this merged into master and then do the following
in the manual:
Document a recommended best practice for custom skin development of copying
one of the provided skin directories and then customizing. Deployers should
be discouraged from modifying any of the provided skins in place.
Suggest (a lighter statement than recommend) that deployers avoid modifying
css/js files in the common directory and instead override styles in their
skin specific CSS.
Document how to generate/capture the CSS output from the SCSS template for a
custom skin if the deployer would rather use CSS instead of SCSS
Document how to use the SASS Watch utility to do CSS development for a custom
skin.
I'm thinking that it would be valuable to consider adding the watch
functionality to the sass-maven-plugin since we'll be adding documentation
for that use of the tool.
The last question is where do we do this? Is deleting the shipped CSS files a
big enough change that this should only happen for 4.1? I'm thinking that is
the case since deleting the .css files could be problematic for folks that
have customized one of the provided skins.
-Eric
On 4/30/12 10:24 AM, Jen Bourey wrote:
My personal thought is that we take option 2 and write clear instructions in
the manual for disabling the SCSS build. We probably also want to document
how to disable it on a skin-specific basis - probably the most likely need
is to know how to let the portal continue using the default behavior for the
built-in skins, but create university-specific skins that don't use SCSS.
- Jen
On Apr 30, 2012, at 6:59 AM, Eric Dalquist wrote:
I have a snapshot of a sass compiling maven plugin deployed, the source is
here: https://github.com/Jasig/sass-maven-plugin
I've created a branch of uPortal to figure out how we move forward with
this: https://github.com/Jasig/uPortal/tree/UP-3456
Issue 1:
When I generated the CSS files from the SASS templates the resulting CSS
didn't match what was already in git. You can see the diffs here:
https://github.com/Jasig/uPortal/commit/9256edc359e9face91d98f2fa190b3cd9114f3b7
It looks like most of the changes are formatting, I'm wondering if there is
something I need to change in the generated ruby script that compiles the
templates or the version of SASS being used. The only existing maven
artifact for SASS I could find is 3.1.15 though that only appears to be a
point release behind the current version. I've pasted the script at the
bottom of this email.
Issue 2
What is our long term project config goal. Do we want both the SCSS and CSS
files in git and we just use the mvn task to re-generate them when needed?
Or do we remove the CSS files from git and generate them at build time
using the mvn task?
For option 1 the advantage is that deployers don't need to learn SCSS/SASS
the CSS files are there for them to use and just work. The downside is that
we have to remember to only update the SCSS files during uPortal
development and to regenerate the CSS files as needed.
For option 2 the advantage is we remove what is effectively generate code
form the git repo and never have to worry about the CSS being out of date.
On the down side if deployers want to use CSS and non SCSS they need to
copy the generated files back into the source tree and disable the SCSS
plugin. This is doable but we would need to document it VERY WELL.
-Eric
Ruby script as generated by the plugin:
require 'rubygems'
require 'sass/plugin'
Sass::Plugin.options.merge!(
:cache_location = 'uportal-war/target/sass_cache',
:cache = true,
:unix_newlines = true,
:always_update = true
)
Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/muniversality/common/scss',
'uportal-war/src/main/webapp/media/skins/muniversality/common')
Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/universality/coal/scss',
'uportal-war/src/main/webapp/media/skins/universality/coal')
Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/universality/common/scss',
'uportal-war/src/main/webapp/media/skins/universality/common')
Re: [uportal-dev] [VOTE] Jacob Lichner for uPortal commit access
+1 Gary - Original Message - From: Eric Dalquist eric.dalqu...@doit.wisc.edu To: uportal-dev@lists.ja-sig.org Sent: Friday, October 7, 2011 11:04:28 AM GMT -07:00 U.S. Mountain Time (Arizona) Subject: [uportal-dev] [VOTE] Jacob Lichner for uPortal commit access I'd like to propose Jacob Lichner as a uPortal developler. Jacob has done a lot of work on the UI and related bits for uPortal 4.0 and he continues to be a valuable contributor. -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] UP-2921: Donate Fluid portlet CSS improvements back to Fluid project
Hey, I wanted to give an update on the work being done for UP-2921 . This work has two parts, 1) to make improvements to FSS (which uPortal uses as the base for skins), and 2) to donate uPortal's portlet.css to the Fluid community to become part of FSS. The Fluid team has been addressing #1 in their current Infusion 1.4 work. You can see the roadmap here: http://wiki.fluidproject.org/display/fluid/FSS+1.4+-+1.5+Roadmap I have been working on #2, which is also FLUID-4024: http://issues.fluidproject.org/browse/FLUID-4024 I finished a first pass of the FSS portlet CSS work yesterday and attached it to the issue (fss-portlet-css.zip): http://issues.fluidproject.org/secure/attachment/11660/fluid-portlet-css.zip Once unzipped, launch fss_portlet.html. I tried to document the portlet css with an html mock portal and some static examples from uPortal. Under the hood, the css files to be considered are fss-layout-portlet and fss-theme-portlet. Please take a look at it and let me know your feedback. Thanks, Gary -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Popular portlets portlet
Drew, Fantastic! I think it would be good to support both Option 1 and Option 2. I know of popular use cases for each. For Option 1 (Admin), I could see where having the ability to see what portlets are most used within the Portlet Manager would be good. It could also be a standalone portlet that resides alongside the portlet manager in the admin dashboard. In this context, I would suggest the title to be Most Added Portlets. For Option 2 (Everyone), this portlet seems like a good default for most institutions for the general populace (assuming end-user customization is allowed). People new to the portal could see what is most popular. In this context I would use the title: Most Popular Apps or something similar. Gary - Original Message - From: Drew Wills awi...@unicon.net To: uportal-dev@lists.ja-sig.org Sent: Friday, March 18, 2011 12:32:50 PM GMT -07:00 U.S. Mountain Time (Arizona) Subject: [uportal-dev] Popular portlets portlet Hey folks, I've prototyped a new framework portlet that provides a report of Popular Portlets -- which portlets have been added to layouts by users and how often. I'm attaching a screenshot. It uses the uPortal database stats, specifically the 'LAYOUT_CHANNEL_ADDED' events (so they must be enabled to use it). The user has specify how far back he/she wants the data to go: 1, 7, 30, 90, or 365 days. Like other framework portlets, it's based on a webflow. It includes a RESTful, json-based API for accessing the counts. Admins can see all portlets in the report, but non-admins can only see portlets for which they have SUBSCRIBE permission. Users can click through the name of a portlet in the report to use it now. I'd like to pick the brains of those on this list over this question: what use(s) should we put this portlet to? Option 1: For admins -- Provide either a new portlet, a subflow off of the portlet-manager, or both. Admins can use the full power of the portlet to audit which portlets are popular with users who customize their layouts. Option 2: For everyone Provide a portlet with perhaps limited features (maybe can't see counts, can't see as far back, etc.) for everyone. This portlet could help users become aware of portal content they might be interested in. Please share your thoughts on these use cases, what titles instructions should appear on the UI, etc. thanks! drew wills -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: g...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] Customize Portal Gallery
Good news! On behalf of BYU, Unicon is designing and implementing a new interface to customizing the portal: content, layout, and skins. The new interface is being called the gallery. The proposed design is a huge improvement to the user experience. You can check out the design here: https://wiki.jasig.org/display/UPC/Customize+Portal+Gallery This work will be done in trunk for the next major release. All feedback is welcome. Gary Thompson User Experience Leader Unicon | www.unicon.net -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Setting Up uPortal 3.2 for Front-End Development
Robert,
As Arlo mentioned, you will need to disable the JS/CSS caching by commenting
out the pageCachingFilter from web.xml as well as changing the caching
properties in portal.properties.
For 3.2, you will additionally have to disable the aggregration of the JS/CSS
files (which puts all of the files of like kind into a single file). There is a
handy portlet for this called Toggle Resources Aggregation. You may need to add
this portlet to your layout. The portlet has a simple button that turns the
aggregation of the files on/off. Disable the aggregation to have the portal
refer to the un-mininfied, non-aggregated versions of the JS/CSS files.
Gary Thompson
User Experience Leader
Unicon | www.unicon.net
- Original Message -
From: Arlo White awh...@calpoly.edu
To: uportal-dev@lists.ja-sig.org
Cc: Robert R. Miller II rr...@cornell.edu
Sent: Thursday, May 27, 2010 10:15:25 AM GMT -07:00 U.S. Mountain Time
(Arizona)
Subject: Re: [uportal-dev] Setting Up uPortal 3.2 for Front-End Development
There was some talk about making this easier to do...
On 3.1.2 I do this (these settings may have changed in 3.2 though):
Edit: /uportal-impl/src/main/resources/properties/portal.properties
Set XSLT caching off:
org.jasig.portal.utils.XSLT.stylesheet_set_caching=off
org.jasig.portal.utils.XSLT.stylesheet_root_caching=off
Edit: /uportal-war/src/main/webapp/WEB-INF/web.xml
Turn off JS/CSS caching, without doing this JS/CSS changes require a app
server restart.
Comment or delete the following sections:
filter
filter-namepageCachingFilter/filter-name
filter-classorg.springframework.web.filter.DelegatingFilterProxy/filter-class
init-param
param-nametargetFilterLifecycle/param-name
param-valuetrue/param-value
/init-param
/filter
filter-mapping
filter-namepageCachingFilter/filter-name
url-pattern*.js/url-pattern
url-pattern*.css/url-pattern
/filter-mapping
To make it easier to deploy updates I added these targets to build.xml
target name=css.directInject description=Directly inject css files
to deploy location and overwrites *.min.css files
!-- Copy all skins files --
copy toDir=${server.webapps}/ROOT/media/skins verbose=true
fileset dir=uportal-war/src/main/webapp/media/skins
include name=**/* /
/fileset
/copy
!-- Overwrite *.min.css files with uncompressed files --
copy toDir=${server.webapps}/ROOT/media/skins verbose=true
fileset dir=uportal-war/src/main/webapp/media/skins
include name=**/*.css /
/fileset
globmapper from=*.css to=*.min.css /
/copy
/target
target name=xsl.directInject description=Directly inject xsl theme
files to deploy location
!-- Copy all skins files --
copy
toDir=${server.webapps}/ROOT/WEB-INF/classes/layout/theme/universality
verbose=true
fileset dir=uportal-war/src/main/resources/layout/theme/universality
include name=**/*.xsl /
/fileset
/copy
/target
Your workflow should now just be to edit XSL or CSS files and then run
ant xsl.directInject or css.directInject
I think the user session still caches XSL, so you may have to logout and
log back in for an XSL change. Better than having to restart the server
though. Maybe there's a way to disable the user's session from caching
XSL so you can just click refresh instead of relogging?
-Arlo
On 05/27/2010 09:45 AM, Robert R. Miller II wrote:
Hey there uPortal community.
I am new to the uPortal development effort so please forgive me for having to
ask the newbie questions. We are attempting a development effort centered
around front-end theme and skin work, starting from the
uPortal-3.2.1-quick-start-dev tarball, and need to know how to effectively
disable the caching in order to increase productivity. We have had no success
with the following 3.1 instruction set
(http://www.ja-sig.org/wiki/display/UPM31/20+Developing+in+the+Themes+and+Skins+Areas+of+uPortal)
and am, at this point, reaching out to the community for some assistance.
Any and all responses to this general inquiry would be greatly appreciated.
Thanks in advance to those who do respond.
~R
Robert R Miller II
Lead Programmer/Analyst
Integrated Web Services
Cornell Information Technologies
Cornell University
(607) 254-5196
Become the change you seek in the world!
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
g...@unicon.net
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] pre-commit hook re: svn:mime-type preventing commit
I have run into this same error using TortoiseSVN (SVN GUI for Windows) when adding new files. My config file looks correct, but I continue to get the error. No resolution thus far. Gary Thompson - Original Message - From: Nicholas Blair nicholas.bl...@gmail.com To: uportal-dev@lists.ja-sig.org Sent: Sunday, February 28, 2010 5:02:44 PM GMT -07:00 U.S. Mountain Time (Arizona) Subject: Re: [uportal-dev] pre-commit hook re: svn:mime-type preventing commit I'll give it a shot next time I have to add a new file. On Sun, Feb 28, 2010 at 12:09 PM, Cris J Holdorph holdo...@unicon.net wrote: So do you see the same behavior if you do the the subversion add from the command line? Cris J H Nicholas Blair wrote: Via eclipse. I'm using the have the JavaHL client. I should add I've added one line to the uportal subversion config as prescriped by subclipse to deal with a subversion bug that appears when using the gnome-keyring: password-stores = On Sun, Feb 28, 2010 at 11:39 AM, Cris J Holdorph holdo...@unicon.net wrote: Did you do the subversion add from the command line or from eclipse? If from eclipse, does anyone know if subclipse will use/pick up those parts of the subversion config file? Cris J H Nicholas Blair wrote: I have the uportal subversion config file from http://www.ja-sig.org/wiki/display/UPC/uPortal+3+Subversion+Configuration in my .subversion directory (Eclipse Galileo, latest subclipse plugin, ubuntu karmic workstation), but every time I try to commit a new file I get the following message copied at the bottom of this message. It doesn't seem to be an issue for commits on existing files, only on new files. I looked at the svn properties for the file in question, and the following exist: svn:eol-style native svn:keywords Date Revision Author HeadURL Id These properties match values on other files in the same directory. Any ideas Error message below: Transmitting file data ... A repository hook failed svn: Commit failed (details follow): svn: 'pre-commit' hook failed with error output: Running /jasig/tools/subversion/subversion/bin/svnlook changed /jasig/svn/jasig -t 48014-1 Running /jasig/tools/subversion/subversion/bin/svnlook proplist /jasig/svn/jasig -t 48014-1 --verbose uPortal/branches/working-pluto-2.0/uportal-impl/src/main/java/org/jasig/portal/spring/locator/PortalDriverContainerServicesLocator.java /jasig/svn/jasig/hooks/check-mime-type.pl: uPortal/branches/working-pluto-2.0/uportal-impl/src/main/java/org/jasig/portal/spring/locator/PortalDriverContainerServicesLocator.java : svn:mime-type is not set Every added file must have the svn:mime-type property set. In addition text files must have the svn:eol-style property set. For binary files try running svn propset svn:mime-type application/octet-stream path/of/file For text files try svn propset svn:mime-type text/plain path/of/file svn propset svn:eol-style native path/of/file You may want to consider uncommenting the auto-props section in your ~/.subversion/config file. Read the Subversion book (http://svnbook.red-bean.com/), Chapter 7, Properties section, Automatic Property Setting subsection for more help. -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: nicholas.bl...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: nicholas.bl...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: g...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Recent CSS update
Eric, Thanks for the feedback, I have looked at all your points and made adjustments to the skin. Just checked in. Gary - Original Message - From: Eric Dalquist eric.dalqu...@doit.wisc.edu To: uportal-dev@lists.ja-sig.org Cc: Gary Thompson g...@unicon.net Sent: Tuesday, January 5, 2010 10:41:48 AM GMT -07:00 U.S. Mountain Time (Arizona) Subject: [uportal-dev] Recent CSS update Gary, A few questions and comments about the recent CSS update. -The text in the portlet chrome title bars seems a bit light. -The defaults for table borders seems to have changed and enabled them, this has the potential to visually break a lot of portlets. -The difference in the UI for a locked portlet doesn't seem to actually describe that the portlet is locked. -The borders around the links in the sidebar seem either too stand out a lot more than the previous version. -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re:[uportal-dev] uPortal skin CSS
Updates and more ideas for uPortal skin CSS: 1. Thanks Jen for completing the work to combine and rename the skin CSS files (http://www.ja-sig.org/issues/browse/UP-2389). The simplicity is fantastic. 2. As a follow-up I completed UP-2525 (http://www.ja-sig.org/issues/browse/UP-2525) to restructure and clean up the Ivy skin. While I was working with the skins, these thoughts occurred to me and I would like to offer them as suggestions: 3. It would be great to use Fluid Skinning System themes as-is and (like all the other 3rd party stuff) keep them separate. This would make it easier to upgrade FSS, and we could hopefully see more efficiency, especially as we hope to move more of the portlet CSS into FSS. This keep the portal.css file simpler, though in the near-term their might still be a fair number of overrides to the FSS theme. We can include the FSS themes on the Resource Server with the rest of the Fluid files, and if necessary, a skin could create a local FSS theme if needed. I believe that with the new aggregator, we can simply call the FSS theme CSS in skin.xml, then remove the FSS theme CSS from portlet.css, which would then only contain FSS overrides. 4. If #3 is accomplished, I think we could quickly generate a couple more default skins to ship with uPortal based off of the exisiting FSS themes (coal, mist, rust, high-contrast), which would be a nice addition. I know it is getting late in the release cycle to add this additional change (#3), but I believe it could be accomplished quickly. Gary Thompson User Experience Leader Unicon | www.unicon.net -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] uPortal skin CSS
Eric, If I understand the work done for UP-2505, there will not be a need for a main CSS file that imports other CSS files as this new aggregator will be doing that? With that consideration, and some further thought on naming, I would like to propose this for uPortal skins: [skinDirectory] - portal.css - portlet.css - thumb.gif - [images] 1. [skinDirectory] This directory is named with the skin name. Everything contained in this folder should be named generically (i.e., not include the skin name in file names). 2. portal.css The primary, portal-scoped CSS file and the new version of the fluid.theme.skinname.css file. Includes the Fluid Skinning System theme and uPortal-specific CSS. Overrides to FSS or jQueryui will be done in this file, if necessary. This will eliminate the previous jquery.css file. 3. portlet.css Portlet-scoped CSS file that replaces the previous uportal3_portlet_content.css and includes the JSR-168 CSS spec. Eliminates the previous jsr168_portlet_spec.css . 4. thumb.gif Remove the skin name from the file name. Every skin's thumbnail file will be named thumb.gif. 5. [images] The images directory remains unchagned. Any skin-specific images go here. As part of these changes, we retire these CSS files: - skinname.css (no longer needed with the new aggregator) - jquery.css (overrides to jQueryui to be done in the new portal.css) - jsr168_portlet_spec.css (included in portlet.css) - skinname_legacy.css (no longer needed) - skinname_ie6overrides.css (with the sunset of IE6, this is not needed by default; can be added as necessary) For namespacing, I suggest adding the up namespace and keeping the fluid-theme-name classes on the body of the document: body class=up fluid-theme-uportal This keeps support for the Fluid Skinning System and other Fluid components, while allowing for the global up namespace that will facilitate not having to change that namespace in all the CSS files. As is the current uPortal 3.x setup, Universality skins will continue to include these common (non-skinned) files: - layout.css - print.css Overrides to layout.css should be done in portal.css or portlet.css as needed. Gary Thompson User Experience Leader Unicon | www.unicon.net - Original Message - From: Eric Dalquist eric.dalqu...@doit.wisc.edu To: uportal-dev@lists.ja-sig.org Cc: Jen Bourey jbou...@unicon.net, Matt Polizzotti mpolizzo...@unicon.net, Alex Bussa abu...@unicon.net, uportal-dev uportal-dev@lists.ja-sig.org Sent: Friday, November 20, 2009 7:29:33 AM GMT -07:00 U.S. Mountain Time (Arizona) Subject: Re:[uportal-dev] uPortal skin CSS This sounds like a great proposal both for simplifying the skin file names as well as the CSS class names. I just wanted to make sure that you're also aware of the work that Nick Blair has been doing on http://www.ja-sig.org/issues/browse/UP-2505 The result of this work will be a skin.xml file in each skin directory. This file will list all CSS and JS files the skin uses in the order they should be imported. I don't think these two sets of changes will cause each other any issues. Something that will help with the aggregation that this new skin.xml and plugin provides is to as much as possible have CSS files listed so that files in the same directory are next to each other. The reason is if skin.xml lists: /path/to/skin/main.css /path/to/common/common.css /path/to/skin/portlet.css That can't be aggregated to reduce the number of files the browser downloads, where as the following: /path/to/common/common.css /path/to/skin/main.css /path/to/skin/portlet.css Could be aggregated down to a two files for the users browser to download. -Eric Gary Thompson wrote: As you know, we've been looking at refining uPortal CSS files. A significant part of this is to accomplish UP-2389 ( http://www.ja-sig.org/issues/browse/UP-2389 ), and in general to make the process of creating and maintaining skins easier. I wanted to run this proposal past you and get any feedback before I post it to the list. Here's the proposal: The root skin directory alone contains the unique skin name, for example uportal3. Each skin would contain these files: [skinDirectory] - main.css - fss-theme-uportal.css - portlet.css - thumb.gif - [images] The new structure does the following: 1. main.css A repalcement of the previous, skin-specific uportal3.css file, this CSS will contain imports of any other skin CSS files, and is the file linked to from the portal head. 2. fss-theme-uportal.css The primary, portal-scoped CSS file and the new version of the fluid.theme.uportal3.css file. Formatted as Fluid Skinning System theme and follows the updated FSS file naming. Overrides to FSS or jQueryui will be done in this file, if necessary. This will eliminate the previous jquery.css file 3. portlet.css Portlet-scoped CSS file that replaces the previous uportal3_portlet_content.css
Re:[uportal-dev] [jasig-ue] portlet UI design guidelines?
-cascade-item-selected Selected sub-menu item that has
sub-menus.
portlet-menu-descriptionDescriptive text for the menu (e.g. in
a help context below the menu).
portlet-menu-captionMenu caption.
Why we need to specifically delineate portlet-menu-item on the li (when the
li is contained in a ul already specified as a portlet-menu) is lost on
me, but okay. And we're supposed to put in a CSS class
portlet-menu-item-hover for mouse-hover? Isn't there such a thing as :hover
in the CSS spec itself? There's some stuff in there that could be used (though
a Menu caption? Really? And the desciption is so helpful.), but the point is
that even something as basic as a menu is not well designed or defined in the
JSR-168 CSS spec. And note there is no JSR-168 class for the associated
tabpanel.
Taking these classes we could add in the following to our markup:
div class= fl-container-flex
ul role=tablist class= fl-tabs fl-tabs-left portlet-menu
li role=tab class= fl-activeTab portlet-menu-item-selected a href=
#_bottom Active Tab /a /li
li role=tab class=portlet-menu-item a href= #_bottom Tab #2 /a
/li
li role=tab class=portlet-menu-item a href= #_bottom Tab #3 /a
/li
/ul
div role=tabpanel class= fl-tab-content
Content
/div
/div And we would discover that this has done very little to our UI result in
2.5.3. Still no tabs, just an unordered list with maybe a bit of styling
applied. Why? Because there is no context. What KIND of menu is this? Nothing
in the JSR-168 spec specifies this as a TAB menu. Well, we could define that in
the CSS by making all .portlet-menu .portlet-menu-item elements inline or
floated and so forth. Super! (except that you had to figure out and test that
across browsers on your own effort, which is painful, trust me). Now we have
tabs from our unordered list. But wait - now EVERYWHERE that these classes are
used will be converted to TABS, whether they are contextually tabs or not. The
JSR-168 spec does not give us classes to define the context.
So, okay, we could add the context to the container div, like so:
div class= fl-container-flex portlet-menu-tabs
ul role=tablist class= fl-tabs fl-tabs-left portlet-menu
li role=tab class= fl-activeTab portlet-menu-item-selected a href=
#_bottom Active Tab /a /li
li role=tab class=portlet-menu-item a href= #_bottom Tab #2 /a
/li
li role=tab class=portlet-menu-item a href= #_bottom Tab #3 /a
/li
/ul
div role=tabpanel class= fl-tab-content
Content
/div
/div And then solve the problem in the CSS with selectors like:
.portlet-menu-tabs .portlet-menu .portlet-menu-item {}
So that only those specifications are applied to make an unordered list into
tabs when the parent .portlet-menu-tabs class is present. However, now we have
broken the standard. No one will get the benefit of using these classes to
achieve tabs from an unordered list without knowing to put the
.portlet-menu-tabs class on the containing element. And even if that class is
on the containing element, if you take the portlet out of uPortal and try to
use it elsewhere, it will revert to an undesireable, plain unordered list. You
could say the same about FSS (that it isn't portable), but it IS easily
includable and relieves us from having to solve the problem, test the solution,
and maintain the standard.
My recommendation: include FSS into your CSS includes in your 2.5.3 skin
(minimally fss-layout.css), and you will at least get the basic structural
benefits without doing any extra work and without complicating the markup with
the JSR-168 classes. Besides, after including the JSR-168 classes, if you were
to stumble on this markup, which classes do you use/modify? The FSS ones, or
the JSR-168 ones? And if they are both (FSS and JSR-168) trying to make tabs
out of an unordered list, you are going to get some ugly CSS conflicts. I like
to Keep It Simple. The FSS markup is much cleaner, and does the job much
better, with little effort required on your part as the implementor.
Hope that helps. I welcome more discussion on these matters.
Gary Thompson
User Experience Leader
Unicon | www.unicon.net
- Original Message -
From: Gary Weaver gary.wea...@duke.edu
To: jasig...@lists.ja-sig.org
Sent: Thursday, October 15, 2009 10:51:42 AM GMT -07:00 U.S. Mountain Time
(Arizona)
Subject: Re:[jasig-ue] portlet UI design guidelines?
I should probably clarify that in the MailPortlet when you click on a
tab, that it when it queries the pop3/imap server for mail, so I'm not
looking for a show/hide div type of thing, but rather either the
standard CSS classes that display line-items horizontally (in a way
friendly to various existing skins in both uPortal 2.5.3 and uPortal
3.1.1) or something (that I'm not guessing would be a simple?) that not
only display tabs but would use Ajax to load the chosen tab in the
background and to do this in a skin-friendly way (specifically
Re: [uportal-dev] Portlet Administration Portlet Update (UP-2047)
+1 This is a great improvement to the user experience. Gary Thompson User Experience Leader Unicon | www.unicon.net - Original Message - From: Eric Dalquist eric.dalqu...@doit.wisc.edu To: uportal-dev@lists.ja-sig.org Sent: Wednesday, May 20, 2009 1:21:40 PM GMT -07:00 U.S. Mountain Time (Arizona) Subject: Re: [uportal-dev] Portlet Administration Portlet Update (UP-2047) +1 as well. If we can perhaps get this switch done by the end of next week I could get a 3.2.0-M1 release and quickstart (before I disappear into a 3 week vacation in June) to give people a chance to play with the new portlet manager and provide feedback. -Eric Cris J Holdorph wrote: +1 for removing the old CChannelManager and switching over to the new one in trunk. I don't say this lightly either. I know there is some risk here, but I think this is a HUGE improvement and is worth the risk. Cris J H Jen Bourey wrote: Hi all, The new Portlet Administration Portlet described by JIRA entry UP-2047 is now in the trunk, and I believe we've updated it to include all features currently available in CChannelManager. I would like to be able to switch the admin link in the layout over to use this new portlet. Does anyone have an objection to making this new portlet the default portlet administration tool sometime in the near future? Are there features you rely on in CChannelManager that don't appear to be included in the new portlet? We've also had discussions in the uPortal IRC channel about potentially removing CChannelManager altogether for the 3.2 release. Doing this would allow us to move forward with the proposed portlet workflow lifecycle work without having to worry about its affects on the legacy channel implementation. - Jen -- Jen Bourey -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: holdo...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] Markup and CSS standards for uPortal and portlet user interface development
Having long desired to see our community standardize on markup and css for UI development, and being knee-deep in developing the new Portlet Administration portlet http://www.ja-sig.org/wiki/x/BwBPAQ (UP-2047 http://www.ja-sig.org/issues/browse/UP-2047), I have put down a proposal here: User Interface http://www.ja-sig.org/wiki/display/UPC/User+Interface With two related child pages: * Markup and CSS Naming Conventions http://www.ja-sig.org/wiki/display/UPC/Markup+and+CSS+Naming+Conventions * Portlet Markup Template http://www.ja-sig.org/wiki/display/UPC/Portlet+Markup+Template This proposal builds on past efforts http://www.ja-sig.org/wiki/display/UPC/Themes+and+Skins, manifests discussions I have had with many of you, reflects threads from this list, and is an extension of the recent integration of the Fluid Skinning System in 3.1. There's still work to be done, so please review and refine. Kindly post your feedback, comments, and input to this thread so we can all benefit from the collaboration. I will be following this proposal myself for completing the development of the first-pass Portlet Administration portlet http://www.ja-sig.org/wiki/x/BwBPAQ UI. -Gary -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Stylesheet imports in uPortal 3.1.x
Can I +10 that idea? That would be fantastic.
There are some workable means to get into a groove with the uPortal
environment for UI development, but (as with all the Web) the UI layer
is becoming more complex. Having an easy means to tell uPortal I'm
doing UI development would be most beneficial.
-Gary
Eric Dalquist wrote:
I think this is a great idea. One thing I'd like to see along with
this work is figuring out a UI developer mode for the portal. This
would likely need to be a configuration property somewhere that is set
before the portal is deployed. It would need to control the following:
- Use full JS/CSS files, no minification or aggregation.
- Disable all JS/CSS/Image caching
- Disable rendering pipeline caching
- Enable logging of pipeline XSL output
Not sure exactly how one configuration change would do all of that but
it sure seems like a common need for uPortal deployers.
-Eric
Jen Bourey wrote:
Hello all,
I wanted to open up discussion about our options for decreasing the
number of HTTP requests for CSS stylesheets in the uPortal 3.1
branch. Currently the portal's skins generally import some shared
default resources from the new ResourceServingWebapp and from the
theme's common area. These resources include the jQuery UI default
theme, the Fluid Skinning System (FSS)'s standard resources, and a
base uPortal-specific layout.css file. The skin then overrides and
adds to these more general CSS styles, generally through including
several more stylesheets.
While I think the above works well from a development standpoint, we
currently have 14 HTTP requests for CSS stylesheets just for the base
uPortal content (i.e., this count doesn't include any stylesheets for
portlets present on the page). I'd really like to get this number
down as much as we can, while making sure we have a skin organization
that's reasonable to work with.
My current proposal is that we leave the existing structure as is,
but make use of the maven yui-compressor plugin to aggregate the
required files at build time. This would allow us to continue to
have separate, appropriately named files, but only require the user's
browser to download one or two CSS file per skin. For example, we
might create aggregated files as follows:
aggregations
!-- Create the shared Fluid Skinning System stylesheet --
aggregation
output${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.fss.min.css/output
includes
include${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.reset.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.layout.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.text.min.css/include
/includes
/aggregation
!-- Create the uPortal3 skin stylesheet --
aggregation
output${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3.min.css/output
includes
include${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/print.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/layout.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jsr168_portlet_spec.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jquery.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/fluid.theme.uportal3.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_portlet_content.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_ie6override.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css/include
/includes
/aggregation
!-- More skins here . . . --
/aggregations
One disadvantage of this approach is that it would likely be less
transparent to adopters how the CSS is being assembled. I'd imagine
that we'd at least want to have a README file in the skins/uportal3
directory that commented on the approach.
Thoughts?
- Jen
--
Jen Bourey
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
Re: [uportal-dev] Copying a Skin in 3.1
I am all in favor of making skin development easy, as I skin uPortal on
a regular basis. Therefore, I have great empathy (and sometimes
sympathy) for others who have to skin uPortal, which is why a main aim
in the 3.0/3.1 theme and skin enhancements was to make theme
customizations and skinning easier.
One way to make skinning easier was to adopt the Fluid Skinning System
http://wiki.fluidproject.org/x/96M7 (FSS). As part of that adoption,
the uportal3 skin was formatted as a FSS theme
http://wiki.fluidproject.org/x/egNS. Which I know is a bit confusing
as FSS labels a theme what uPortal calls a skin.
In following FSS theme best practices, the skin CSS file is given this name:
fluid.theme.[theme_name].css
Which is why the uportal3 main skin CSS file is named:
fluid.theme.uportal3.css
Continuing in the pattern of a FSS theme, many of the uportal3 CSS files
follow this syntax:
.fl-theme-uportal3 h2 {color:#5a95cf;}
Which uses the theme name (e.g., .fl-theme-uportal3) in all CSS
declarations.
So, to answer the question: Is there a strong technical reason that the
root CSS class name for a skin contains the skin name?
The most simple answer is, that's how FSS does it. Which I know isn't
very satisfying, and though I had some sense of why FSS chose to do it
that way, I put the question to Jacob Farber (U of Toronto), Shepherd of
the Fluid Skinning System. Here's what Jacob said:
Jacob
I hope I understood the question, which I took it to be: why should
someone add a class name to all of their selectors?
There are a few reasons why we namespace our css themes with a class name:
Reduce collisions: we can work side by side with other themes if need be
and don't need to worry about colliding
Greater control: by adding a class name, we gain specificity in the
selector and increase our chance of affecting the nodes we're interested in
Ease of use: we only need to switch a class name to switch a theme,
rather than load and manage non-namespaced CSS files
In the end, one doesn't need to have any prefix to their theme - you
would be working at the same level as a CSS reset file - however the
uportal prefix enables you to load and control multiple themes on the
page without worrying about messy collisions and cross-theming.
The fewer selectors you use the weaker your hold on your desired effect is.
Additionally, namespacing themes is how UI Options
http://wiki.fluidproject.org/x/B6E7 works with them, so if it needs to
work with UI Options it needs to be namespaced.
/Jacob
And for this question: Can we find an alternate solution that doesn't
require as much work for the deployer to create a new skin?
One truth we need to face is that the uPortal UI layer is (and probably
will continue to become) more complex. This is not unique to uPortal,
but is a trend across the Web, a la Web 2.0, rich user interfaces, etc.
We are using 3rd party libraries like Fluid, jQuery, and Silk Icons
We are using more and more JavaScript
We have adopted the FSS
We are supporting legacy uPortal CSS
We are supporting the JSR-168 spec CSS
We have to support older browsers (like IE6)
We need to be accessible and must comply to accessibility law
And all this must be performant (part of the whole user experience), so
We are using a resource server for 3rd party resources
We are minifying and caching CSS and JS files
And as a portal (which is pointing to applications and content of
various nature from varied sources), we take the approach that we are
not the only player in the game, so
We must practice namespacing
I must admit, adding the namespace to all CSS selectors in the skin does
add to the effort of maintenance, but I find that effort sufferable for
the benefits. I have created a new skin from the 3.1 uportal3 skin a
couple of times already, and I find that doing a find and replace in the
CSS files takes less than 5 minutes.
I re-quote Jacob:
Jacob
In the end, one doesn't need to have any prefix to their theme - you
would be working at the same level as a CSS reset file - however the
uportal prefix enables you to load and control multiple themes on the
page without worrying about messy collisions and cross-theming.
/Jacob
Personally, I would not consider this a blocker issue, but rather a
reasonable and manageable effort to achieve a best practice. However, I
also realize that there may be better ways and means, and I am all for
thinking it through to get to the best result.
-Gary
Eric Dalquist wrote:
I'm working on our vendor branch merge for 3.1 and ran into what I
consider a blocker of an issue. What has been recommended in the past
when doing local skinning work for uPortal is to create a copy of the
default uportal3 skin with a new name. When doing so I realized that
the new theme uses the skin name as part of the base CSS class name.
This means the skin name is hardcoded in the skin CSS files ... 251
times. I realize a search and replace
Re: [uportal-dev] Stylesheet imports in uPortal 3.1.x
I'd like to see:
- Enable flawless rendering in all browsers
But I don't think I am going to get that one. Otherwise, what you have
listed would be my list as well (that's what I usually do manually when
doing UI development).
-Gary
Eric Dalquist wrote:
Are there any other settings you'd like to see toggled in a UI Dev
Mode?
Gary Thompson wrote:
Can I +10 that idea? That would be fantastic.
There are some workable means to get into a groove with the uPortal
environment for UI development, but (as with all the Web) the UI
layer is becoming more complex. Having an easy means to tell uPortal
I'm doing UI development would be most beneficial.
-Gary
Eric Dalquist wrote:
I think this is a great idea. One thing I'd like to see along with
this work is figuring out a UI developer mode for the portal. This
would likely need to be a configuration property somewhere that is
set before the portal is deployed. It would need to control the
following:
- Use full JS/CSS files, no minification or aggregation.
- Disable all JS/CSS/Image caching
- Disable rendering pipeline caching
- Enable logging of pipeline XSL output
Not sure exactly how one configuration change would do all of that
but it sure seems like a common need for uPortal deployers.
-Eric
Jen Bourey wrote:
Hello all,
I wanted to open up discussion about our options for decreasing the
number of HTTP requests for CSS stylesheets in the uPortal 3.1
branch. Currently the portal's skins generally import some shared
default resources from the new ResourceServingWebapp and from the
theme's common area. These resources include the jQuery UI default
theme, the Fluid Skinning System (FSS)'s standard resources, and a
base uPortal-specific layout.css file. The skin then overrides and
adds to these more general CSS styles, generally through including
several more stylesheets.
While I think the above works well from a development standpoint,
we currently have 14 HTTP requests for CSS stylesheets just for the
base uPortal content (i.e., this count doesn't include any
stylesheets for portlets present on the page). I'd really like to
get this number down as much as we can, while making sure we have a
skin organization that's reasonable to work with.
My current proposal is that we leave the existing structure as is,
but make use of the maven yui-compressor plugin to aggregate the
required files at build time. This would allow us to continue to
have separate, appropriately named files, but only require the
user's browser to download one or two CSS file per skin. For
example, we might create aggregated files as follows:
aggregations
!-- Create the shared Fluid Skinning System stylesheet --
aggregation
output${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.fss.min.css/output
includes
include${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.reset.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.layout.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.text.min.css/include
/includes
/aggregation
!-- Create the uPortal3 skin stylesheet --
aggregation
output${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3.min.css/output
includes
include${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/print.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/layout.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jsr168_portlet_spec.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jquery.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/fluid.theme.uportal3.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_portlet_content.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_ie6override.min.css/include
include${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css/include
/includes
/aggregation
!-- More skins here . . . --
/aggregations
One
Re: [uportal-dev] Theme / Skin
Wanted to give everyone a summary of my theme and skin work for the upcoming 3.1 release. This is not the limit of the 3.1 theme and skin work, but simply my contribution. 1. Accessibility http://www.ja-sig.org/wiki/display/UPC/Accessibility On behalf of the Fluid Project, I have been working on making out-of-the-box uPortal complaint with WCAG 2 Level 1. With the exception of several of the admin administrative channels/portlets, this work is complete. Refer to: http://www.ja-sig.org/wiki/display/UPC/Accessibility UP-2266Accessibility - missing alternate desciption for images in Change Layout UP-2267Accessibility - missing label for Web Search input UP-2270Accessibility - inline style set on login form inputs UP-2274Accessibility - anchor tags missing text UP-2277Accessibility - poor markup and spacer gifs in sitemap UP-2288Accessibility - missing form markup, poor markup, and spacer gifs in Admin channels and portlets PBOOK-74Accessibility - missing labels on form inputs 2. Theme Standardizing on the Fluid Skinning System for a CSS and markup strategy, several changes were made to integrate FSS, as well as some other enhancements. Reference: Fluid Skinning System (FSS) http://wiki.fluidproject.org/x/96M7 UP-2285Move print and layout CSS to common area UP-2286Add Fluid Skinning System to universality theme UP-2287Convert universality theme column layout markup to use divs instead of a table (This also included converting the main navigation to use FSS tabs) UP-2302Add display options to channel publishing workflow 3. Skin The default skin, uportal3, was entirely re-worked to be aligned with FSS themes and was visually updated to reflect the recent Jasig and uPortal brand redesign. Reference: FSS Walk-through - Colors and Themes http://wiki.fluidproject.org/x/egNS Reference: http://www.jasig.org/ UP-2292Convert uportal3 skin to FSS format and update to new Jasig brand This work also included implementing the INSTITUTION variable in the universality theme so that parts of the theme can be configured based on the skin or group of skins. -- Still to be done: 1. More testing Although we've done some testing, more detailed testing, and particularly cross-browser testing with your institution's specific content would be very much appreciated. I am certain that there are still some kinks to be ironed out and bugs to be fixed. 2. Document theme and skin changes I know how difficult it can be coming at uPortal's theme and skin without supporting information. I've tried to be liberal with inline comments on the theme and skin code, but a theme and skin primer on the wiki would likely be beneficial for everyone, especially with all of the 3.1 changes. Any help with this process would be greatly appreciated. Reference: uPortal 3.0 Manual 03 Theme and Skin http://www.ja-sig.org/wiki/x/SoCV 3. Integrate Fluid User Interface Options I plan on including a link labeled My Preferences in the Customize My Portal links (in the right sidebar when logged in) that invokes the Fluid UI Options component. I had hoped to add that in for the 3.1 release as a preview, but didn't get to it, and am not sure of it being default when UI Options is still considered Beta. UI Options should reach official release status in the Fluid Infusion 1.0 release, but uPortal will also need to be modified to interact with personal user preferences. Reference: User Interface Options http://wiki.fluidproject.org/x/B6E7 -- Let me know if there are questions or comments. -Gary -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Theme / Skin
Eric, I believe that I have everything tested and checked in for the theme and skin. Let me know if anyone encounters issues. Gary Gary Thompson wrote: I'm glad I'm not the only one. My home internet went out about 10:30pm last night when I was wanting to do an update and check in. When my internet was still out at 11:30pm, I gave up greatly frustrated, so I am glad to hear that today affords the opportunity to finish. Gary Eric Dalquist wrote: Since this isn't going to be the default skin that is fine, I'm still a bit behind in getting fixes merged in so I probably won't get to cutting the RC until tomorrow morning. Just watch this list for the announcement of the code freeze while I'm getting the release cut. -Eric Matt Polizzotti wrote: All, As of right now, the additional 'new' skin and options drop-down menu are not complete enough to check in. I feel confident that I can complete these today. Unfortunately, I did not have enough time to complete these tasks to a decent level of quality over the weekend. Regardless of this, I intend to move forward and donate these pieces at some point today. Is there any chance that these pieces can still be added to the 'new' release if checked in late? Thanks, Matt -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Theme / Skin
I'm glad I'm not the only one. My home internet went out about 10:30pm last night when I was wanting to do an update and check in. When my internet was still out at 11:30pm, I gave up greatly frustrated, so I am glad to hear that today affords the opportunity to finish. Gary Eric Dalquist wrote: Since this isn't going to be the default skin that is fine, I'm still a bit behind in getting fixes merged in so I probably won't get to cutting the RC until tomorrow morning. Just watch this list for the announcement of the code freeze while I'm getting the release cut. -Eric Matt Polizzotti wrote: All, As of right now, the additional 'new' skin and options drop-down menu are not complete enough to check in. I feel confident that I can complete these today. Unfortunately, I did not have enough time to complete these tasks to a decent level of quality over the weekend. Regardless of this, I intend to move forward and donate these pieces at some point today. Is there any chance that these pieces can still be added to the 'new' release if checked in late? Thanks, Matt -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Proposing Matt Polizzotti for commit access
+1 Jen Bourey wrote: Hi everyone, I'd like to nominate Matt Polizzotti for commit access for uPortal. For those of you who don't know him, he is a Unicon developer and has been instrumental in fixing a number of the CSS and Javascript bugs in uPortal 3.x. In particular, he's provided patches for some of the persistent IE 6 and 7 issues we've had that have been difficult to debug. Matt's also implemented large parts of the UP-2047 work (the proposed portlet manager portlet: http://www.ja-sig.org/wiki/display/UPC/Portlet+Manager+Portlet). He also was involved in the Johns Hopkins mobile theme work. I've really appreciated Matt's assistance and fixes, and to date, I've happily applied patches on his behalf. However, I'd love for him to be able to contribute to the uPortal project without having to wait on me. He has some great work planned helping us clean up our current CSS stylesheets and update them to better support Safari, as well as adding some cool new features. Also, once we move the UP-2047 development over to the uPortal trunk, allowing Matt to continue to easily collaborate on that work would greatly help that ticket's progress. Thanks! - Jen -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: g...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] channel/tab terminology
What's in a name? Choosing terminology should be done with consideration as it has profound effect on comprehension, expectations, and findability. I would say that historically the uPortal community has chosen terms largely on the consideration of technology correctness. If a change is to be made, I would propose that the following guidelines: 1. Where possible, follow convention. People are comforted by recognizing familiar terms and labels which translates into increased confidence and satisfaction. The term shopping cart, for example. Breaking this convention simply confuses people, and there really isn't much sense in otherwise mis-labeling or coining a new term unless innovation demands it. We need not simply follow what Google or Yahoo does, but these two carry significant weight in setting and establishing convention. iGoogle uses: tab for a discreet section of layout, and stuff or gadget for content. My Yahoo uses: page for a discreet section of layout, and module or RSS feed for content. 2. No technical jargon - express everything in plain language. Unless the audience is solely or primarily technical. Only a very limited segment of the uPortal audience is going to care if a box of content is technically a channel or portlet. But everyone is going to need to know what to call said box of content. How can the average person make sense of managed fragment without an in-depth explanation from Andrew Petro? 3. Use a singular term whenever possible. Especially in the case of channel and portlet. Let's find one term that can adequately cover them both and use it consistently. I can guarantee that confusion will decrease across the board. 4. Be just enough specific. Keep the terms as familiar and generic as possible to gain the greatest audience comprehension. iGoogle's use of stuff, for example. Everyone knows what stuff is (given the context of iGoogle) and there is really no reason to try and be more specific. I would suggest the following: tab for a discreet section of layout, and portlet for content. If uPortal comes to a place where there is a three-tier structure, then I would suggest: tab page portlet. Overall, I think portlet is debatable, and that ultimately there is a better term. But for the near-term, it would be good to standardize and to Cris' point, portlet is more future-oriented. Perhaps the good news is that with uPortal 3, the theme labels are localizable such that portlet can be called channel, box, stuff, thingamabob, or whatever is desired. But please deviate with prudence. Gary Jen Bourey wrote: First of all, I probably should have clarified that I'm only looking at the AJAX UI, UI links, etc. at the moment, so terms like managed fragment shouldn't be of concern. I also object to the use of portlet as a generic term. It's driven me partially insane since the day we started using it. I'm completely OK with sticking with channel and tab, although since some other terminology has crept into the UI, so it seems worthwhile to solicit some opinions about which direction we should fix it in. My preference would be to someday replace the term channel with something that's neither channel nor portlet. Ideally I'd really rather use a term that doesn't indicate (or mis-indicate) a backing technology. That doesn't necessarily need to happen now though. - Jen On Tue, Mar 25, 2008 at 1:19 PM, Andrew Petro [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Jen, I favor sticking with the historical tab and channel terminology for this release. It maximizes the re-usability of existing documentation. I object to portlet as the generic term for the dynamic boxes on the screen in the uPortal documentation and terminology because it is confusing in its relationship to JSR-168 Portlets. Some of the channels are implemented as JSR-168 portlets. Some are not. Technically, all of them are channels and can benefit by channel things, like channel types, metadata about which channel controls to show, categorization, and selection of audiences permitted to subscribe to them. I see why implementing schools might adopt portlet, or widget, or channel, or thingamabob as their local terminology. End users don't need to understand JSR-168 and the distinction of which channels are JSR-168 portlets and which are not. The target audience of the uPortal release, however, tends more towards the IT staff of higher education institutions who might adopt and implement uPortal locally. Avoiding calling things portlets that are not Portlets has value for this audience. I like the term tab. Using the default theme and skin, they look like tabs. I find it easier to explain this to people in terms of tabs, and then tell them that if they want they could look like something other than tabs. Tabs
Re: [uportal-dev] Portlet type identifier
This sounds like a good starting approach - not that I can really weigh in on the framework implementation - but the end result of having attributes on the channel elements should do the job. That then also opens up a means for specifying channels to render borderless, highlighted, alternate, or other possibilities. It would be good to have the Set Channel Attributes page be a default part of the publishing process for all channel/portlet types. Gary Eric Dalquist wrote: I believe we're specifically targeting uPortal 3.0 with this feature though as with anything if it works in 2.X no reason not to. In the sandbox code I believe there was a planned concept of portlet/channel attribute sources. These would be additional places that fed attributes on to the channel elements in the layout. I would think in uPortal 2 and 3 this would be fairly reasonable to achieve by adding an additional SAX filter in the rendering chain or in the layout loading code to add these attributes to each channel from some backing store. As long as there isn't a requirement for these to be dynamic I don't think it would have to involve having the caching framework be aware these attributes were being added in. Channel Manager then seems like the appropriate place to configure these, say adding a 'Channel Attributes' page which would allow the portal administrator to set name/value pairs to be set as attributes. Deciding on some well known attribute names could be quite handy for this purpose (channel type) but could also be extended to other things such as css and javascript. The theme transform could be aware of the cssLink attribute: channel cssLink=/uPortal/channel/style.css/ and add all of the CSS links to the head of the rendered content. That should solve your problem Gary, I'd like to hear what other devs think of the idea. If it sounds good I can add it to the list for 3.0 RC2 -Eric Gary Thompson wrote: I am desiring to have icons associated with portlets, at least the main ones (email, calendar, news, announcements, rss, etc.). Do you know of any way to identify the portlet as one of these other than the fname or title? The fname/title will be tricky without some ugly parsing or standardization of naming. It would be nice to have something like a type attribute on the channel node for this, where an email portlet would register itself as type=email, a calender portlet as type=calendar, etc. It could also be done as a custom parameter in the portlet manager, but it would obviously be preferable for the system to do it automatically. Any thoughts? Gary -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re:[uportal-dev] Fluid Re-Orderer uP3
Anastasia, Those are good questions. I believe the answers would be: Locked portlets will always be at the top of their current column. Locked portlets can be present in any column Locked portlets can only be moved by privileged users (likely admins). Users with privilege could drag and drop locked portlets just like other portlets, though their position will follow normal locked portlet rules (always at the top of the column and ordered by priority). This may require changes to uPortal to accomplish. An indication should be given to admin users which portlets are locked. I'll think through that interaction and come up with a design. Gary Anastasia Cheetham wrote: On 2-Jan-08, at 1:59 PM, Gary Thompson wrote: So, my conclusion for the DnD reordering of portlets is to go with our initial gut instinct: * locked portlets always go to the top of column * if there is more than one locked portlet, they are ordered by priority (a system parameter set and changed by an administrator) * reorderable portlets may not go above locked portlets within a column (or between locked portlets if there are more than one) Gary, thanks for doing that research, and producing this summary. Just to clarify: Locked portlets will always be at the top of their current column, but locked portlets can be present in any column? They are not restricted to the leftmost column? Assuming that locked portlets can exist in any column, can they be moved between columns? -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re:[uportal-dev] Fluid Re-Orderer uP3
Fluid and uPortal Reodererists, Happy New Year! I hope that your holiday was joyous. I did some research into use cases for locked portlets. It seems that institutions that do lock portlets do so sparingly with the goal of either: 1. Keeping prioritized content at the top (usually news/announcements content), or 2. Preventing a user from accidentally removing content For #2, this is really more of a problem with the add portlet UI, which has substantial usability problems and is painful. Some institutions lock portlets not because they don't want users to be able to remove the content, but that they get too many tech support calls from users who accidentally removed content they wanted, and then were not able to successfully use the add portlet UI to get it back. So, my conclusion for the DnD reordering of portlets is to go with our initial gut instinct: * locked portlets always go to the top of column * if there is more than one locked portlet, they are ordered by priority (a system parameter set and changed by an administrator) * reorderable portlets may not go above locked portlets within a column (or between locked portlets if there are more than one) With that, I believe that everything remains the same for the DnD design except for the identification of locked portlets as such to the user. Currently, I am thinking that we identify locked portlets to the user on drag attempt with a simple message, something like This portlet is locked and cannot be moved. For reordering of unlocked portlets, it should indicate drop targets above (or between) locked portlets as invalid, and follow normal invalid drop target behavior. Thoughts? Gary Colin Clark wrote: Eric, Good question. Here's a quick overview of where we're at from the client side: * Fluid 0.1 had a bug in it that prevented nested Reorderers from working happily together. Michelle D'Souza managed to commit a fix for this before the holidays, so this problem should now be resolved. * We need to minimize our JavaScript footprint by removing the rest of Dojo from the Reorderer. We've had much better luck with jQuery, and it's generally a bit smaller. Should make for lighter download times for the portal. This work is about half-finished. * Anastasia has an in-progress branch with part of the functionality required for this Fluid portlet layout manager. It's available here: https://source.fluidproject.org/svn/fluid/components/branches/FLUID-49/ Anastasia's core change was to write a new layout handler that uses the layout JSON object sent down from the portal. * We've got to make a couple of API changes to the layout handler to make this code a cleaner and simpler. * Gary Thompson and Shaw-Han Liem are working on making this really easy to use. We've got a new design pattern that outlines some of the considerations, and they're working on new wireframes to ensure the interaction is simple and discoverable. http://wiki.fluidproject.org/display/fluid/Drag+and+Drop+-+Layout+Preview We've been a bit behind schedule on this work, but it is now our top priority for the new year. Have a great holiday, Colin On 21-Dec-07, at 1:11 PM, Eric Dalquist wrote: Anastasia, Jen, Just wondering what the status of looking into using the Fluid reorderer for uPortal 3 is. Thanks, -Eric --- Colin Clark Technical Lead, Fluid Project Adaptive Technology Resource Centre, University of Toronto http://fluidproject.org ___ fluid-work mailing list [EMAIL PROTECTED] http://fluidproject.org/mailman/listinfo/fluid-work -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
