[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 think we are buying unnecessary trouble if we defer this entire issue. I don't like drilling down into details on the particulars of buttons and naming conventions, but I don't see a way around it. This is another case of either inviting a myriad of hard-to-replace practices or setting the least number of options at the highest level possible. I think confining ourselves to current and previous user navigational states for window and mode, with OK, CANCEL AND APPLY seems like the least we need to do to prevent a quagmire of practices to sort out for v1.1-2. Ciao, Rex At 2:27 PM +0200 3/20/03, 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. > >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 -- Rex Brooks Starbourne Communications Design 1361-A Addison, Berkeley, CA 94702 *510-849-2309 http://www.starbourne.com * rexb@starbourne.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]