[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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:richard.jacob@de.ibm.com
|---------+---------------------------->
| | Alejandro |
| | Abdelnur |
| | <alejandro.abdeln|
| | ur@sun.com> |
| | |
| | 03/14/2003 02:38 |
| | AM |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: |
| cc: wsrp-wsia <wsrp-wsia@lists.oasis-open.org> |
| Subject: Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and "DONE" |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Some questions/comments embedded.
Alejandro
Michael Freedman wrote:
Folks,
A long time ago we decided that the portlet would be responsible
for rendering/managing the buttons commonly displayed in modal MODEs.
For example the portlet renders the "APPLY", "OK", "CANCEL"
What do you mean by modal MODEs?
button in Edit Mode. Likewise the portlet renders the "DONE" button
in Help mode. Unfortunately, our specification doesn't define how a
portlet can accomplish this in ways that meet [what I consider] basic
requirements. Namely, the specification doesn't define a uniform way
for portlets to recognize what Mode the portlet should return to when
"OK", "CANCEL", or "DONE" are invoked. Also the specification
doesn't define a uniform way for portlets to use controls/labels that
are consistent with the portal/consumer they are running in. I feel
we must address these deficiencies in 1.0.
These are the basic requirements I believe we must meet:
Requirements related to managing navigation:
MUST requirements:
1) The specification must describe/define a single mechanism
that allows
any portlet [session-based or otherwise] to implement "Done"
semantics.
"Done" semantics are the ability to optionally accept/process
inputed data in a
mode other then VIEW and then to exit that mode;
Why going back to VIEW/NORMAL would not be enough for the DONE semantics?
Wouldn't this cover most (if not all) cases?
When you say "inputed data in a mode other than VIEW" I assume you refer to
modifying properties in EDIT or the DONE woud be used also when the portlet
is doing a trasaction in VIEW?
generally by returning to the mode from whence the portlet
came.
If a portlet mode transition is VIEW, EDIT, HELP, EDIT, where the DONE
semantics would take me, back to HELP or to VIEW?
2) For portlets using the mechanism defined in (1), the portal
MUST be
able to establish a uniform navigational look and feel. I.e.
users expect portlets in a given consumer to navigate in a
consistent manner.
I assume that by "uniform navigational look and feel" you are meaning
"uniform navigational behavior", right?
I don't know how this could be done as the portal has no way to enforce
portlets to provide the set of buttons that should be displayed in the
portlet content. We could certainly make recommendations, but to me this
belongs to a best practices document.
3) The mechanism defined in (1) must allow allow a return to
modes other
then VIEW. For example, it must be possible for a portal to
indicate that a portlet that navigates from VIEW to EDIT to
HELP will navigate back to EDIT [not VIEW] when the user is
done with HELP mode.
This is implicitly requiring the consumer to keep a history trace per
portlet.
A portlet can keep track of where to go back in the session or in the
navigational state. The latter would not work when the user is clicking on
the controls (VIEW, EDIT, HELP, NORMAL, MINIMIZE, MAXIMIZE) in the portlet
window title bar, we have to see how (or if) we fix this.
4) The mechansim defined in (1) must work for all non-VIEW
modes be they custom or defined by the specification.
SHOULD requirements:
1) The mechanism defined in (1) SHOULD be expressed in our
protocol in an
easy and obvious mannner so portlet developers find it
convenient.
I don't see convenient the fact that a portlet will always have to check
the portletmode and windowstate it will be taken when DONE semantics is
applied. What I'm trying to say is, portlets may decide to set different
navigational state depending on the portletmode and windowstate they are
going. As now it is not the portlet the one deciding the portletmode or
windowstate, the portlet has to check where the portal will take it and
then set the proper navigation state. IMO, this is an unnecessary
complexity forced uppon the developer.
2) A portlet SHOULD be able to ignore the mechanism defined by
(1) and
implement semantics of its choosing [limited by other
constraints
imposed by the portal/container within the bounds of the
specification]. I.e. though we encourage portlets to code
themselves using the proscribed technique, portlets should be
able to do otherwise at a loss of user interface consistency.
I wouldn't say this is a SHOULD requirement, portlets can always do this by
just going to a specific portletmode and windowstate.
Requirements related to the look/feel of the buttons
MUST requirements:
1) The mechanism we define for rendering mode control buttons
MUST allow the portal to maintain a uniform look and feel for
these controls across all portlets it manages.
Yes, I think is a good idea to define CSS classes to be used for buttons
that confirm a task or cancel a task. We could also add (I think it was
proposed in another change request), next-step and previous-step.
2) The mechanism we define for rendering mode control buttons
MUST allow the portal to control the number of buttons/types of
operations to be used in a given Mode. I.e. we mustn't require
EDIT mode have a 'OK', 'APPLY', and 'CANCEL' button. A portal
may have choosen a different combination of these.
I don't understand why a portal would remove buttons from the portlet
content. That's dangerous, it could break portlet functionality encoded in
those actions (as it is not accessible).
It would require the portal to parse the portlet content to do. Or it would
require to pass with the markupParameters the list of buttons the portlet
can use, but still a portlet could create a button not indicated in the
markupParamters.
3) The mechanism we define for rendering mode control buttons
MUST allow the portal to maintain a uniform labeling of these
controls [across locales] across all portlets it manages.
It seems like a good idea but I'm not sure if the practical end result is
desirable. Suppose a portlet that always creates English content. It is
invoked by a userAgent that indicates French locale, the portlet in the
portal page would have all its content in English except for the control
button labels that would be in French.
SHOULD requirements:
1) The mechanism defined in (1) SHOULD be expressed in our
protocol in an
easy and obvious mannner so portlet developers find it
convenient.
Unless I'm missing something, (1) is about adding a set of CSS classes.
The navigational issue is reflected in Change Request #141: Add
previous window state and mode. I will request Rich open a new
change request for the button/control management.
On the navigational issue: [Change Request #141]:
I originally introduced this as a JSR related issue as we first
re-identified it in the JSR EG. Unfortunately, we [the JSR EG] is
having a hard time deciding which of the possible mechanisms
available to us we should use to resolve this issue. As this is an
issue that is equally germane to us, I suggest we tackle this head on
without waiting for JSR to make further progress. In the end our
resolution will likely help JSR come to a conclusion. To get
started, I suggest we first discuss/approve the requirements our
solution should meet. Once there is agreement on this 1 to N options
can be considered for approval based on these requirements. To get
the ball rolling, I will send out another e-mail with 2 distinct
solutions that meet the above requirements.
On the button look/feel issue:
I seem to recall we proposed this would/could be solved using CSS.
Unfortuantely, I am not versed well enough in CSS to propose a
solution. Should we get started by discussing/approving a set or
requirements and then pass these on to the Markup subcommittee [or an
individual volunteer] to make proposal(s)?
-Mike-
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]