[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [Fwd: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CAN CEL" and"DONE"]
I agree,
I think we can't define *the* semantics for buttons. Again I'd like to
repeat myself and state that this should only be done by the application,
i.e. portlet.
To give an example: we state below that APPLY naturally remaines in the
same mode while OK leaves the mode (but to which mode? - here we go with
the definition of back semantics).
But portlets may explicitly want to stay in edit mode for example to
display a success message and point out the changes made and so on.
I think if we ask 10 developers about their semantics of OK, APPLY and
whatever button we get 12 opinions.
Therefor I would hesitate to try to push this into 1.0.
I think we will also may have difficulties to define and agree which
buttons make it into the CSS classes although I think this would be a
reasonable thing to do.
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
|---------+---------------------------->
| | Subbu Allamaraju |
| | <subbu@bea.com> |
| | |
| | 03/20/2003 03:03 |
| | PM |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Eilon Reshef <Eilon.Reshef@webcollage.com> |
| cc: WSRP <wsrp@lists.oasis-open.org> |
| Subject: Re: [Fwd: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CAN CEL" and "DONE"] |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Eilon Reshef wrote:
> I think it's also pretty clear that the entire concept of "modes" is a
poor
> man's way to try to put structure to applications (=portlets). As
portlets
> become more complex (=have more business value), the distinction between
> help, view and edit blurs (e.g., context sensitive help, multiple levels
of
> customization, remembering the last user state, etc.), and hence this
> structure loses much of its value.
Well said. I agree with you. I would like to add the following:
- It is fairly easy to come up with portlets that don't rely on modes
for any structure/flow, or use some other mechanism for managing
structure/flow.
- Not all applications share the same sense of what terms like APPLY,
OK, CANCEL mean.
Regards,
Subbu
> Thus, I am also of the opinion that rather than trying to squeeze in more
> heuristics around behavior of pre-named buttons, we defer this to a
larger
> topic in subsequent versions of the protocol.
>
> Eilon
>
> -----Original Message-----
> From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
> Sent: Thursday, March 20, 2003 11:34
> To: WSRP
> Subject: RE: [Fwd: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK",
"CAN
> CEL" and "DONE"]
>
>
> I agree, I would rather have multiple (application dependent) look and
feels
> and associated navigational behaviours rather than one l&f with diverse
> behaviours.
>
> The JSR168 has been discussing various incomplete solutions to the larger
> problem of navigation and I would like to step back and consider a more
> abstract solution that lets either the portal or the portlet implement
> history.
>
> So far, I have been trying to work though the requirements and issues in
the
> JSR 168 and would like to try for a fuller proposal when we have a chance
to
> fully consider these related issues.
>
> regards,
> Andre
>
> -----Original Message-----
> From: Subbu Allamaraju [mailto:subbu@bea.com]
> Sent: 20 March 2003 02:43
> To: WSRP
> Subject: Re: [Fwd: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK",
> "CANCEL" and "DONE"]
>
>
> Are you suggesting that this spec define or standardize what
> APPLY/OK/CANCEL/DONE means? We should try something more abstract.
>
> Subbu
>
> Michael Freedman wrote:
>
>>
>>-------- Original Message --------
>>Return-Path: <Michael.Freedman@oracle.com>
>>Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by
>>rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id
>>h2JJJ9B08607 for <Michael.Freedman@oracle.com>; Wed, 19 Mar 2003
>>12:19:09 -0700 (MST)
>>Received: from oracle.com (mfreedma-pc2.us.oracle.com [130.35.93.129])
>>by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id
>>h2JJJ8o08552; Wed, 19 Mar 2003 12:19:08 -0700 (MST)
>>Message-ID: <3E78C1D6.7030406@oracle.com>
>>Date: Wed, 19 Mar 2003 11:15:34 -0800
>>From: Michael Freedman <Michael.Freedman@oracle.com>
>>Organization: Oracle Corporation
>>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2)
>>Gecko/20021120 Netscape/7.01
>>X-Accept-Language: en-us, en
>>MIME-Version: 1.0
>>To: Rich Thompson <richt2@us.ibm.com>
>>Subject: Re: [wsrp] Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL" and
>>"DONE"
>>References:
>><OF222552DC.F7013FDF-ON85256CEE.006604A8-85256CEE.0066F746@us.ibm.com>
>>Content-Type: multipart/alternative;
>>boundary="------------070303070803040100090707"
>>
>>
>>
>>'OK' means 'Apply' [the changes] and exit this mode. 'Apply' means
>>apply the changes but stay in this mode. -Mike-
>>
>>Rich Thompson wrote:
>>
>>
>>>I thought about this as well as we have done similar in past
>>>projects.
>>>The difficulty is that the Consumer now has to rewrite a significant
>>>part of the portlet's content in a way that still carries the
>>>semantics intended for each control (also, this starts to head down
>>>the path of the Consumer transforming a portion of the markup while
>>>not requiring any particular technology for doing so). The Portlet no
>>>longer knows what controls will exist on the page and therefore has to
>>>write reasonable semantics for each possibility. These are not
>>>difficult things to overcome, but would involve a change in the
>>>abstractness of what the Portlet write as markup. I think v1 should
>>>stick at the simpler concrete level of defining individual classes and
>>>possibly revisit adding more abstract concepts in v2.
>>>
>>>Your comments suggest also adding a "wsrp-ok" class. What would be
>>>the
>>>semantics of the control (distinct from wsrp-apply)?
>>>
>>>Rich Thompson
>>>
>>>
>>>
>>>Michael Freedman <Michael.Freedman@oracle.com>
>>>
>>>03/19/2003 01:27 PM
>>>
>>> To: WSRP <wsrp@lists.oasis-open.org>,
>>>wsrp-wsia@lists.oasis-open.org
>>> cc: Subject: [wsrp] Re: [wsrp-wsia]
>>>Handling "APPLY", "OK", "CANCEL" and "DONE"
>>>
>>>
>>>
>>>
>>>Rich,
>>>Sounds good. I wonder if we can get even simpler on the look side of
>>>things and merely define a style called wsrp-edit-controls and
>>>wsrp-help-controls. The wsrp-edit-controls style would let the
>>>portlet set a apply, cancel, and ok URL. The wsrp-help-controls
>>>would merely let the portlet set a done URL. The advantage I see in
>>>this over your proposal to offer a style per button type is that the
>>>consumer can now control whioch of these buttons they actually want
>>>to display. I.e. One consumer/portal might choose to only have "OK"
>>>and "Cancel" while another also includes the "Apply".
>>>Note: we could even consider getting away with the most minimal
>>>solution that provides only a single style: wsrp-mode-control. With
>>>this style the producer always sets the apply, cancel, and ok URLs.
>>>The consumer exposes buttons/chooses URLs absed on what makes sense
>>>for the mode. For example a consumer might choose to only expose a
>>>"Done" button in help mode and map the cancel [or OK] URL to it.
>>> -Mike-
>>>
>>>
>>>Rich Thompson wrote:
>>>
>>>
>>>>I think the biggest question is how to draw the line so that we
>>>>don't
>>>
>>>have
>>>
>>>>too much of an issue with the slippery slope character of this area.
>>>>We certainly do not want to be defining a metadata language for
>>>>Consumer to declare their control navigational semantics. Nor do we
>>>>want to
>>>
>>>require a
>>>
>>>>particular means for Consumers to do some sort of match and
>>>>transform
>>>
>>>on a
>>>
>>>>Portlet's markup (e.g. XSLT as a means to find/replace control
>>>>specification).
>>>>
>>>>What I think has been proposed is the Consumer supplying information
>>>>so that the Portlet can write navigational semantics that will have
>>>>some consistency with other Portlets on the same page. The only
>>>>candidates
>>>
>>>for
>>>
>>>>additional information of this type that have been raised are
>>>
>>>previousMode
>>>
>>>>and previousWindowState. If these were provided and used by Portlets
>>>>to navigate back, then however the Consumer chooses to set these
>>>>values becomes the level of consistency across its pages.
>>>>
>>>>On the 'Look' side of the house, I think the key is keeping the set
>>>>of additional classes relatively small. Here is a suggestion:
>>>> wsrp-cancel: Semantics = abort the current end-user activity.
>>>> wsrp-apply: Semantics = accept and apply the current end-user
>>>
>>>activity.
>>>
>>>> wsrp-previous: Semantics = navigate to previous page in the
>>>>current end-user activity
>>>> wsrp-next: Semantics = navigate to the next page in the current
>>>
>>>end-user
>>>
>>>>activity
>>>>
>>>>I would suggest we not deal with making a cross product of these
>>>>with
>>>
>>>user
>>>
>>>>interaction (e.g. hover, selected, down, etc.) for v1 as this opens
>>>
>>>issues
>>>
>>>>related to how many such modifiers and how does the class name get
>>>>changed.
>>>>
>>>>Rich Thompson
>>>>
>>>>
>>>>
>>>>
>>>>Michael Freedman <michael.freedman@oracle.com>
>>>>03/17/2003 11:58 AM
>>>>
>>>> To: wsrp-wsia <wsrp-wsia@lists.oasis-open.org>
>>>> cc:
>>>> Subject: Re: [wsrp-wsia] Handling "APPLY", "OK", "CANCEL"
>>>>and "DONE"
>>>>
>>>>
>>>>Folks,
>>>> I wonder if I have created some confusion. I am not suggesting
>>>
>>>that
>>>
>>>>we either define control L/F or navigational semantics that provides
>>>>uniformity accross consumers. I am sugesting we define mechanisms
>>>>so
>>>
>>>that
>>>
>>>>portlet which desire to play by the rules can conveniently implement
>>>>the consumers control L/F and navigational semantics. I.e. we need
>>>>ways in which portlet developers can get at this information/express
>>>>it. We
>>>
>>>don't
>>>
>>>>need to define a common semantic between portals.
>>>>
>>>>On control L/F I am hoping we can get anway with something simple --
>>>
>>>Is it
>>>
>>>>possible to define a CSS which represents the "APPLY, "OK", "CANCEL"
>>>>buttons as a single set? In this CSS a developer would merely set
>>>>the APPLY url, OK url, and Cancel url. The CSS class would take
>>>>care of ordering these, naming these, and potentially even excluding
>>>>unneeded ones. If such a thing is doable then we could consider
>>>>only doing
>>>
>>>the one
>>>
>>>>or providng a separate CSS class for situations where a single
>>>>button "DONE/Cancel/back" would be suitable. Again, in this CSS the
>>>>developer would only provide the URL. The CSS class would define
>>>>the rest.
>>>>
>>>>On the navigational semantics, the problem we have in our protocol
>>>>today is that there is no way for a session-less portlet to do
>>>>anything but hardcode its navigational semantics. I believe this is
>>>>a big
>>>
>>>oversight in
>>>
>>>>our specification -- paticularly when its fairly easy to resolve by
>>>
>>>merely
>>>
>>>>asking the portal to pass information in the request. Since we
>>>>require the portlet to deal with impelmenting portal semantics "OK",
>>>
>>>"CANCEL", etc
>>>
>>>>our protocol should be complete enough so it can do its job.
>>>
>>> Therefore I
>>>
>>>>don't see how this can wait to 1.1 -- as there is no way a hardcoded
>>>>portlet will fit into a future design without rewrite.
>>>> -Mike-
>>>>
>>>>Eilon Reshef wrote:
>>>>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:richard.jacob@de.ibm.com]
>>>>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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]