I would like to second that. I also think that button behavior falls under
application semantics and the less we get into those muddy waters the better
we are, even if some consistency is sacrificed. If people want to develop
bad applications (=portlets) so be it, and we can always add more detailed
_guidelines_ in the next version.
Eilon
-----Original Message-----
From: Richard Jacob [mailto:]
Sent: Monday, March 17, 2003 18:24
To: wsrp-wsia
Subject: Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and "DONE"
I agree that it is desireable to have a common look&feel (and I would say
it's more the "look" than the "feel"). Therfor I would say we should define
a set of CSS classes with common buttons defined as we already discussed. We
need to figure out this set of buttons. Folks with CSS knowledge should try
to bring up a proposal here. Maybe Yossi's example is a good starting point.
It would be also nice to have the button labels localized, but need to make
sure that these is consistent with the markup generated (i.e. english markup
-> english buttons). Also we need to define a fallback behaviour if markup
and buttons locales do not overlap. Also overrides for default text should
be possible?
However I'm not sure about the common navigational semantics. In an ideal
world all UIs would behave consistently. But I think it is pretty hard to
agree on a common behaviour, i.e. semantic definitions for each such button
which satisfies the whole bunch of possible applications. That's why JSR
folks a having a hard time on this, as far as I understood. If you look at
UI's like Windows or KDE, etc. They provide the user with a common look but
every application is free to decide on the semantics on button-actions
(close dialog, display information, etc.) We don't really know what
applications want to code, right? For example a portlet may have different
setup pages in EDIT mode and a "OK" button leads the user back to page one
of EDIT mode for instance - a mode change to "VIEW" wouldn't be the
behaviour the portlet wants. Or assume a wizard like dialog in EDIT mode,
where one OK on one page triggers the portlet to enter yet another EDIT page
depending on the input of the first page. Therefor I wouldn't consider this
part as a "must address" in the 1.0 timeframe. The DONE behaviour you
described could always be coded by the portlet. And I agree there might be
different flavours how portlet application handle this, but...
Concerning your proposal in MUST requirements, look and feel section 2: Do
you propose that the portal should provide the buttons (which, number of
them etc.)? I think the only one knows its semantics is the portlet itself,
so the portlet should request the portal to render the buttons it requests
(using CSS).
Mit freundlichen Gruessen / best regards,
Richard Jacob ______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:
|---------+---------------------------->
| | Alejandro |
| | Abdelnur |
| | <alejandro.abdeln|
| | > |
| | |
| | 03/14/2003 02:38 |
| | AM |
|---------+---------------------------->
