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 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 uportal-dev@lists.ja-sig.org
<mailto:uportal-dev@lists.ja-sig.org> as:
[EMAIL PROTECTED] <mailto:[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 <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 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
--
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 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