Is it possible to use both the terms channel and portlet where appropriate? The word portlet has already sort of been adapted imo...there's wiki pages with the term all over the place.
I also like the term tab. On Tue, Mar 25, 2008 at 12:35 PM, Jen Bourey <[EMAIL PROTECTED]> 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]> 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 are nicely concrete and palpable and easier to grok. I > > like using "managed fragment" to differentiate between DLM managed tabs > > and end-user personal layout tabs. > > > > The term "page" has too much content management system expectations > > associated with it. uPortal *isn't* a content management system and you > > *don't* interact with pages in the sense of Drupal or HyperContent. > > > > Andrew > > > > > > Timothy Carroll wrote: > > > we have implemented a bit more hierarchy than the out of box uportal. > > > > > > we use the terms tabs, pages, portlets > > > > > > > > > > > > Jen Bourey wrote: > > >> Hi all, > > >> > > >> In cleaning up the up3 UI, I've noticed that the terminology isn't > > >> always consistent. What do we want to use? I think historically > > >> we've used channel and tab as terms? At Yale, we've switched to > > >> calling those items portlets and pages, not that that's necessarily > > >> better. > > >> > > >> I don't have strong feelings about what terminology we use, although > > >> I would like to fix it to all be the same. What would everyone > > prefer? > > >> > > >> - Jen > > >> -- > > > > > > -- > > Join your friends and colleagues at JA-SIG 2008 - "Higher Education > > Solutions: The Community Source Way!" > > April 27th - 30th, 2008 in St. Paul, Minnesota USA > > > > Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, > > and more! > > Information/Registration at: > > http://www.ja-sig.org/conferences/08spring/index.html > > > > Subscribe to the conference blog, The Community Source Way > > http://jasig2008.blogspot.com, for news and updates about the event. > > > > Join the Conference networking site at > > http://ja-sigspring08.crowdvine.com/ > > > > You are currently subscribed to [email protected] as: > > [EMAIL PROTECTED] > > To unsubscribe, change settings or access archives, see > > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > > > -- > > Join your friends and colleagues at JA-SIG 2008 - "Higher Education > Solutions: The Community Source Way!" > April 27th - 30th, 2008 in St. Paul, Minnesota USA > > Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and > more! > Information/Registration at: > http://www.ja-sig.org/conferences/08spring/index.html > > Subscribe to the conference blog, The Community Source Way > http://jasig2008.blogspot.com, for news and updates about the event. > > Join the Conference networking site at http://ja-sigspring08.crowdvine.com/ > > You are currently subscribed to [email protected] as: [EMAIL > PROTECTED] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The Community Source Way!" April 27th - 30th, 2008 in St. Paul, Minnesota USA Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and more! Information/Registration at: http://www.ja-sig.org/conferences/08spring/index.html Subscribe to the conference blog, The Community Source Way http://jasig2008.blogspot.com, for news and updates about the event. Join the Conference networking site at http://ja-sigspring08.crowdvine.com/ You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
