Discussion: More UI Layout Best Practices

[Adrian Crum]

As has been discussed in other message threads, some screenlets have
unusual links in their title bars. I'd like to request comments on the
use of links in screenlets and develop a Best Practice for them.

The current use of links in screenlet title bars makes the UI very
inconsistent. On one screen a "Create New" link is a button under the
page title, on another screen it is in the screenlet title bar. On most
screens, a form's Submit button is at the bottom of the form, and in
other screens it is in the screenlet title bar. There are other examples.

To be fair, I originally liked the idea of having list pagination in the
screenlet title bar - like in the Find Party screen. I even gave the
screenlet widget the ability to put a contained form's pagination in
there. But I have changed my mind. That also makes the UI inconsistent
because most lists have their own pagination menus above and below the list.

I'm beginning to think screenlet title bars should contain very little
information: the screenlet title, an optional expand/collapse link, and
an optional Help link. All other links should follow established best
practices - Submit links are at the bottom of forms, Create New links
are at the top of the screenlet body, etc. In other words, follow the
same pattern inside the screenlet that you would follow in the main
content area.

What do you think?

-Adrian

[David E Jones]

On Jul 7, 2008, at 3:55 PM, Adrian Crum wrote:

> As has been discussed in other message threads, some screenlets have  
> unusual links in their title bars. I'd like to request comments on  
> the use of links in screenlets and develop a Best Practice for them.
>
> The current use of links in screenlet title bars makes the UI very  
> inconsistent. On one screen a "Create New" link is a button under  
> the page title, on another screen it is in the screenlet title bar.  
> On most screens, a form's Submit button is at the bottom of the  
> form, and in other screens it is in the screenlet title bar. There  
> are other examples.

Fortunately this is pretty rare in OFBiz. I say fortunately because  
this is one of the biggest travesties in UI design that I've ever  
seen. It slows users down at best, and stops first-time users dead in  
their tracks trying to find the stupid button because it's not at the  
bottom of the form where EVERY submit button in the world is. Having  
other links in the header along with the form submit makes it even  
worse because when submitting the form it is easy to miss and click on  
one of those, killing your work in the form. I don't know where this  
came from, but it's awful and we should never do it.

One interesting thing that I think is okay (but not great) in the  
header bar is wizard progress links, like in the checkout process in  
the order manager. Still, even that would be better as buttons with  
arrows pointing to the right between them or something, and just below  
the screenlet header... or better yet get rid of the header altogether  
because it's ugly.

> To be fair, I originally liked the idea of having list pagination in  
> the screenlet title bar - like in the Find Party screen. I even gave  
> the screenlet widget the ability to put a contained form's  
> pagination in there. But I have changed my mind. That also makes the  
> UI inconsistent because most lists have their own pagination menus  
> above and below the list.
>
> I'm beginning to think screenlet title bars should contain very  
> little information: the screenlet title, an optional expand/collapse  
> link, and an optional Help link. All other links should follow  
> established best practices - Submit links are at the bottom of  
> forms, Create New links are at the top of the screenlet body, etc.  
> In other words, follow the same pattern inside the screenlet that  
> you would follow in the main content area.

Yes, they should have very little in them. I agree with that. There  
could certainly be exceptions, but that's a good guideline.

BTW, on style: the dark blue headers on these are a little bit...  
well... "heavy" might be the right word. If anyone want to play with  
making this prettier maybe something lighter would be nice, but that's  
really another topic and anyone with a text editor and a basic  
knowledge of CSS can change that to their liking.

-David

[Bruno Busco]

I agree with these guidelines also (only title, expand/collapse button and
optional help link in the screenlet title bar and the submit at the bottom).

Moreover I am thinking to a general FindScreen standard layout and
functional improvement that I briefly describe here hoping not being OT.
It would be great IMO to have in the list form of every FindScreen
(optionally) a first column of check boxes that let the user to select
several items and than a combo box above the list that let the user to
select a command to execute on them.
Basically this is how gmail looks like.
I would like for example to use this to select several product to change
their image with in a single shot, or to include all of them in the
promotion category.
I am thinking how to implement this (already received some hint by you on
using the multi form) but may be some other hint could be beneficial.

Thank you,
Bruno


2008/7/8 David E Jones <jonesde@...>:

>
> On Jul 7, 2008, at 3:55 PM, Adrian Crum wrote:
>
>  As has been discussed in other message threads, some screenlets have
>> unusual links in their title bars. I'd like to request comments on the use
>> of links in screenlets and develop a Best Practice for them.
>>
>> The current use of links in screenlet title bars makes the UI very
>> inconsistent. On one screen a "Create New" link is a button under the page
>> title, on another screen it is in the screenlet title bar. On most screens,
>> a form's Submit button is at the bottom of the form, and in other screens it
>> is in the screenlet title bar. There are other examples.
>>
>
> Fortunately this is pretty rare in OFBiz. I say fortunately because this is
> one of the biggest travesties in UI design that I've ever seen. It slows
> users down at best, and stops first-time users dead in their tracks trying
> to find the stupid button because it's not at the bottom of the form where
> EVERY submit button in the world is. Having other links in the header along
> with the form submit makes it even worse because when submitting the form it
> is easy to miss and click on one of those, killing your work in the form. I
> don't know where this came from, but it's awful and we should never do it.
>
> One interesting thing that I think is okay (but not great) in the header
> bar is wizard progress links, like in the checkout process in the order
> manager. Still, even that would be better as buttons with arrows pointing to
> the right between them or something, and just below the screenlet header...
> or better yet get rid of the header altogether because it's ugly.
>
>  To be fair, I originally liked the idea of having list pagination in the
>> screenlet title bar - like in the Find Party screen. I even gave the
>> screenlet widget the ability to put a contained form's pagination in there.
>> But I have changed my mind. That also makes the UI inconsistent because most
>> lists have their own pagination menus above and below the list.
>>
>> I'm beginning to think screenlet title bars should contain very little
>> information: the screenlet title, an optional expand/collapse link, and an
>> optional Help link. All other links should follow established best practices
>> - Submit links are at the bottom of forms, Create New links are at the top
>> of the screenlet body, etc. In other words, follow the same pattern inside
>> the screenlet that you would follow in the main content area.
>>
>
> Yes, they should have very little in them. I agree with that. There could
> certainly be exceptions, but that's a good guideline.
>
> BTW, on style: the dark blue headers on these are a little bit... well...
> "heavy" might be the right word. If anyone want to play with making this
> prettier maybe something lighter would be nice, but that's really another
> topic and anyone with a text editor and a basic knowledge of CSS can change
> that to their liking.
>
> -David
>
>

[jacques.le.roux]

From: "Bruno Busco" <bruno.busco@...>
>I agree with these guidelines also (only title, expand/collapse button and
> optional help link in the screenlet title bar and the submit at the bottom).

+1
 

> Moreover I am thinking to a general FindScreen standard layout and
> functional improvement that I briefly describe here hoping not being OT.
> It would be great IMO to have in the list form of every FindScreen
> (optionally) a first column of check boxes that let the user to select
> several items and than a combo box above the list that let the user to
> select a command to execute on them.
> Basically this is how gmail looks like.
> I would like for example to use this to select several product to change
> their image with in a single shot, or to include all of them in the
> promotion category.
> I am thinking how to implement this (already received some hint by you on
> using the multi form) but may be some other hint could be beneficial.

Sounds good to me

Jacques

> Thank you,
> Bruno
>
>
> 2008/7/8 David E Jones <jonesde@...>:
>
>>
>> On Jul 7, 2008, at 3:55 PM, Adrian Crum wrote:
>>
>>  As has been discussed in other message threads, some screenlets have
>>> unusual links in their title bars. I'd like to request comments on the use
>>> of links in screenlets and develop a Best Practice for them.
>>>
>>> The current use of links in screenlet title bars makes the UI very
>>> inconsistent. On one screen a "Create New" link is a button under the page
>>> title, on another screen it is in the screenlet title bar. On most screens,
>>> a form's Submit button is at the bottom of the form, and in other screens it
>>> is in the screenlet title bar. There are other examples.
>>>
>>
>> Fortunately this is pretty rare in OFBiz. I say fortunately because this is
>> one of the biggest travesties in UI design that I've ever seen. It slows
>> users down at best, and stops first-time users dead in their tracks trying
>> to find the stupid button because it's not at the bottom of the form where
>> EVERY submit button in the world is. Having other links in the header along
>> with the form submit makes it even worse because when submitting the form it
>> is easy to miss and click on one of those, killing your work in the form. I
>> don't know where this came from, but it's awful and we should never do it.
>>
>> One interesting thing that I think is okay (but not great) in the header
>> bar is wizard progress links, like in the checkout process in the order
>> manager. Still, even that would be better as buttons with arrows pointing to
>> the right between them or something, and just below the screenlet header...
>> or better yet get rid of the header altogether because it's ugly.
>>
>>  To be fair, I originally liked the idea of having list pagination in the
>>> screenlet title bar - like in the Find Party screen. I even gave the
>>> screenlet widget the ability to put a contained form's pagination in there.
>>> But I have changed my mind. That also makes the UI inconsistent because most
>>> lists have their own pagination menus above and below the list.
>>>
>>> I'm beginning to think screenlet title bars should contain very little
>>> information: the screenlet title, an optional expand/collapse link, and an
>>> optional Help link. All other links should follow established best practices
>>> - Submit links are at the bottom of forms, Create New links are at the top
>>> of the screenlet body, etc. In other words, follow the same pattern inside
>>> the screenlet that you would follow in the main content area.
>>>
>>
>> Yes, they should have very little in them. I agree with that. There could
>> certainly be exceptions, but that's a good guideline.
>>
>> BTW, on style: the dark blue headers on these are a little bit... well...
>> "heavy" might be the right word. If anyone want to play with making this
>> prettier maybe something lighter would be nice, but that's really another
>> topic and anyone with a text editor and a basic knowledge of CSS can change
>> that to their liking.
>>
>> -David
>>
>>
>

[Adrian Crum]

David E Jones wrote:
> BTW, on style: the dark blue headers on these are a little bit...
> well... "heavy" might be the right word. If anyone want to play with
> making this prettier maybe something lighter would be nice, but that's
> really another topic and anyone with a text editor and a basic knowledge
> of CSS can change that to their liking.

If no one gets to it first, I'll work on the styles sometime in the near
future. I still want to go through the main style sheet and remove all
of the deprecated styles. I could also change the title bar darkness
while I'm at it.

Now that we have the user preferences feature in the framework, the
possibility arises that we could have UI themes. Color attributes and
background url attributes could be kept in separate CSS files that are
loaded depending upon a user's preference setting.

-Adrian

[Adrian Crum]

David E Jones wrote:
> One interesting thing that I think is okay (but not great) in the header
> bar is wizard progress links, like in the checkout process in the order
> manager. Still, even that would be better as buttons with arrows
> pointing to the right between them or something, and just below the
> screenlet header... or better yet get rid of the header altogether
> because it's ugly.

Hey now, it's not ugly! Beauty is in the eye of the beholder. ;-)

I agree there is an overuse of screenlets. If one is used, I like the
idea of having breadcrumbs under the title bar.

-Adrian

[hansbak]

talking about preferences feature...wouldn't it be nice if the screenlet
collapse is automatically remembered per user......

On Tue, 2008-07-08 at 07:20 -0700, Adrian Crum wrote:

> David E Jones wrote:
> > BTW, on style: the dark blue headers on these are a little bit...
> > well... "heavy" might be the right word. If anyone want to play with
> > making this prettier maybe something lighter would be nice, but that's
> > really another topic and anyone with a text editor and a basic knowledge
> > of CSS can change that to their liking.
>
> If no one gets to it first, I'll work on the styles sometime in the near
> future. I still want to go through the main style sheet and remove all
> of the deprecated styles. I could also change the title bar darkness
> while I'm at it.
>
> Now that we have the user preferences feature in the framework, the
> possibility arises that we could have UI themes. Color attributes and
> background url attributes could be kept in separate CSS files that are
> loaded depending upon a user's preference setting.
>
> -Adrian
>

[Adrian Crum]

Hans Bakker wrote:
> talking about preferences feature...wouldn't it be nice if the screenlet
> collapse is automatically remembered per user......

It depends upon the screenlet. In some cases that might be unexpected
behavior. In other words, users might expect a screenlet to be expanded
until they collapse it.

-Adrian

[Anil Patel-3]

Sometime back I discussed similar things with Andrew and Tim at that  
time they suggested to instead integrate Portal server into Ofbiz and  
have portal server manage all that. I liked it because then we are  
more in line with industry standards.

Regards
Anil Patel

On Jul 8, 2008, at 11:31 AM, Adrian Crum wrote:

> Hans Bakker wrote:
>> talking about preferences feature...wouldn't it be nice if the  
>> screenlet
>> collapse is automatically remembered per user......
>
> It depends upon the screenlet. In some cases that might be  
> unexpected behavior. In other words, users might expect a screenlet  
> to be expanded until they collapse it.
>
> -Adrian

[Adrian Crum]

An interesting idea, but it looks like it overlaps a lot of the OFBiz
framework. I believe Apache Directory would be be more appropriate.

-Adrian

Anil Patel wrote:

> Sometime back I discussed similar things with Andrew and Tim at that
> time they suggested to instead integrate Portal server into Ofbiz and
> have portal server manage all that. I liked it because then we are more
> in line with industry standards.
>
> Regards
> Anil Patel
>
> On Jul 8, 2008, at 11:31 AM, Adrian Crum wrote:
>
>> Hans Bakker wrote:
>>> talking about preferences feature...wouldn't it be nice if the screenlet
>>> collapse is automatically remembered per user......
>>
>> It depends upon the screenlet. In some cases that might be unexpected
>> behavior. In other words, users might expect a screenlet to be
>> expanded until they collapse it.
>>
>> -Adrian
>

[Anil Patel-3]

I did not understand how  "Apache Directory" is more appropriate.

What I mean is, There is UI behavior improvements that can be  
implemented in ofbiz. Significant chunk of it comes as part of Portal  
server implementation. Like its will be lot nicer if we did "Party  
Profile" type page in Portal.  Ofbiz Portlets "which is something  
similar to ofbiz screenlets" be lot more Portable in enterprise. Like  
we will be able to deliver them thru any other standard compliant  
Portal Server.

Regards
Anil Patel




On Jul 8, 2008, at 1:07 PM, Adrian Crum wrote:

> An interesting idea, but it looks like it overlaps a lot of the  
> OFBiz framework. I believe Apache Directory would be be more  
> appropriate.
>
> -Adrian
>
> Anil Patel wrote:
>> Sometime back I discussed similar things with Andrew and Tim at  
>> that time they suggested to instead integrate Portal server into  
>> Ofbiz and have portal server manage all that. I liked it because  
>> then we are more in line with industry standards.
>> Regards
>> Anil Patel
>> On Jul 8, 2008, at 11:31 AM, Adrian Crum wrote:
>>> Hans Bakker wrote:
>>>> talking about preferences feature...wouldn't it be nice if the  
>>>> screenlet
>>>> collapse is automatically remembered per user......
>>>
>>> It depends upon the screenlet. In some cases that might be  
>>> unexpected behavior. In other words, users might expect a  
>>> screenlet to be expanded until they collapse it.
>>>
>>> -Adrian

[Bruno Busco]

Regarding the commands menu at the top of the screenlet I like how gmail
does:
The main commands have an own command button (max three of them) and then
all other commands are in a sort of drop down menu with a "other actions"
label.
Could this be useful in ofbiz also?

-Bruno

2008/7/8 Anil Patel <anil.patel@...>:

> I did not understand how  "Apache Directory" is more appropriate.
>
> What I mean is, There is UI behavior improvements that can be implemented
> in ofbiz. Significant chunk of it comes as part of Portal server
> implementation. Like its will be lot nicer if we did "Party Profile" type
> page in Portal.  Ofbiz Portlets "which is something similar to ofbiz
> screenlets" be lot more Portable in enterprise. Like we will be able to
> deliver them thru any other standard compliant Portal Server.
>
> Regards
> Anil Patel
>
>
>
>
>
> On Jul 8, 2008, at 1:07 PM, Adrian Crum wrote:
>
>  An interesting idea, but it looks like it overlaps a lot of the OFBiz
>> framework. I believe Apache Directory would be be more appropriate.
>>
>> -Adrian
>>
>> Anil Patel wrote:
>>
>>> Sometime back I discussed similar things with Andrew and Tim at that time
>>> they suggested to instead integrate Portal server into Ofbiz and have portal
>>> server manage all that. I liked it because then we are more in line with
>>> industry standards.
>>> Regards
>>> Anil Patel
>>> On Jul 8, 2008, at 11:31 AM, Adrian Crum wrote:
>>>
>>>> Hans Bakker wrote:
>>>>
>>>>> talking about preferences feature...wouldn't it be nice if the
>>>>> screenlet
>>>>> collapse is automatically remembered per user......
>>>>>
>>>>
>>>> It depends upon the screenlet. In some cases that might be unexpected
>>>> behavior. In other words, users might expect a screenlet to be expanded
>>>> until they collapse it.
>>>>
>>>> -Adrian
>>>>
>>>
>

[jacques.le.roux]

From: "Bruno Busco" <bruno.busco@...>
> Regarding the commands menu at the top of the screenlet I like how gmail
> does:
> The main commands have an own command button (max three of them) and then
> all other commands are in a sort of drop down menu with a "other actions"
> label.
> Could this be useful in ofbiz also?

Yes, I think so. Note that the same is duplicated at the bottom. This makes sense. In Rich Client Application (Desktop), in most of
the cases, the page is not scrollable. Hence, most of the time, the buttons at the right bottom only. But on Internet, even with
Rich Intenet Application, the page is scrollable. Hence the duplication. I think this is a must-be in a modern Internet interface.

Hence, each screnlet (portlet ?) could support this pattern

Jacques

> -Bruno
>
> 2008/7/8 Anil Patel <anil.patel@...>:
>
>> I did not understand how  "Apache Directory" is more appropriate.
>>
>> What I mean is, There is UI behavior improvements that can be implemented
>> in ofbiz. Significant chunk of it comes as part of Portal server
>> implementation. Like its will be lot nicer if we did "Party Profile" type
>> page in Portal.  Ofbiz Portlets "which is something similar to ofbiz
>> screenlets" be lot more Portable in enterprise. Like we will be able to
>> deliver them thru any other standard compliant Portal Server.
>>
>> Regards
>> Anil Patel
>>
>>
>>
>>
>>
>> On Jul 8, 2008, at 1:07 PM, Adrian Crum wrote:
>>
>>  An interesting idea, but it looks like it overlaps a lot of the OFBiz
>>> framework. I believe Apache Directory would be be more appropriate.
>>>
>>> -Adrian
>>>
>>> Anil Patel wrote:
>>>
>>>> Sometime back I discussed similar things with Andrew and Tim at that time
>>>> they suggested to instead integrate Portal server into Ofbiz and have portal
>>>> server manage all that. I liked it because then we are more in line with
>>>> industry standards.
>>>> Regards
>>>> Anil Patel
>>>> On Jul 8, 2008, at 11:31 AM, Adrian Crum wrote:
>>>>
>>>>> Hans Bakker wrote:
>>>>>
>>>>>> talking about preferences feature...wouldn't it be nice if the
>>>>>> screenlet
>>>>>> collapse is automatically remembered per user......
>>>>>>
>>>>>
>>>>> It depends upon the screenlet. In some cases that might be unexpected
>>>>> behavior. In other words, users might expect a screenlet to be expanded
>>>>> until they collapse it.
>>>>>
>>>>> -Adrian
>>>>>
>>>>
>>
>

[Adrian Crum]

Anil,

I think I found what you are talking about -

http://developers.sun.com/portalserver/reference/techart/jsr168/

Is that correct?

-Adrian

Anil Patel wrote:

> I did not understand how  "Apache Directory" is more appropriate.
>
> What I mean is, There is UI behavior improvements that can be
> implemented in ofbiz. Significant chunk of it comes as part of Portal
> server implementation. Like its will be lot nicer if we did "Party
> Profile" type page in Portal.  Ofbiz Portlets "which is something
> similar to ofbiz screenlets" be lot more Portable in enterprise. Like we
> will be able to deliver them thru any other standard compliant Portal
> Server.
>
> Regards
> Anil Patel
>
>
>
>
> On Jul 8, 2008, at 1:07 PM, Adrian Crum wrote:
>
>> An interesting idea, but it looks like it overlaps a lot of the OFBiz
>> framework. I believe Apache Directory would be be more appropriate.
>>
>> -Adrian
>>
>> Anil Patel wrote:
>>> Sometime back I discussed similar things with Andrew and Tim at that
>>> time they suggested to instead integrate Portal server into Ofbiz and
>>> have portal server manage all that. I liked it because then we are
>>> more in line with industry standards.
>>> Regards
>>> Anil Patel
>>> On Jul 8, 2008, at 11:31 AM, Adrian Crum wrote:
>>>> Hans Bakker wrote:
>>>>> talking about preferences feature...wouldn't it be nice if the
>>>>> screenlet
>>>>> collapse is automatically remembered per user......
>>>>
>>>> It depends upon the screenlet. In some cases that might be
>>>> unexpected behavior. In other words, users might expect a screenlet
>>>> to be expanded until they collapse it.
>>>>
>>>> -Adrian
>

[Anil Patel-3]

Yes.

Regards
Anil Patel

On Jul 9, 2008, at 1:38 PM, Adrian Crum wrote:

> Anil,
>
> I think I found what you are talking about -
>
> http://developers.sun.com/portalserver/reference/techart/jsr168/
>
> Is that correct?
>
> -Adrian
>
> Anil Patel wrote:
>> I did not understand how  "Apache Directory" is more appropriate.
>> What I mean is, There is UI behavior improvements that can be  
>> implemented in ofbiz. Significant chunk of it comes as part of  
>> Portal server implementation. Like its will be lot nicer if we did  
>> "Party Profile" type page in Portal.  Ofbiz Portlets "which is  
>> something similar to ofbiz screenlets" be lot more Portable in  
>> enterprise. Like we will be able to deliver them thru any other  
>> standard compliant Portal Server.
>> Regards
>> Anil Patel
>> On Jul 8, 2008, at 1:07 PM, Adrian Crum wrote:
>>> An interesting idea, but it looks like it overlaps a lot of the  
>>> OFBiz framework. I believe Apache Directory would be be more  
>>> appropriate.
>>>
>>> -Adrian
>>>
>>> Anil Patel wrote:
>>>> Sometime back I discussed similar things with Andrew and Tim at  
>>>> that time they suggested to instead integrate Portal server into  
>>>> Ofbiz and have portal server manage all that. I liked it because  
>>>> then we are more in line with industry standards.
>>>> Regards
>>>> Anil Patel
>>>> On Jul 8, 2008, at 11:31 AM, Adrian Crum wrote:
>>>>> Hans Bakker wrote:
>>>>>> talking about preferences feature...wouldn't it be nice if the  
>>>>>> screenlet
>>>>>> collapse is automatically remembered per user......
>>>>>
>>>>> It depends upon the screenlet. In some cases that might be  
>>>>> unexpected behavior. In other words, users might expect a  
>>>>> screenlet to be expanded until they collapse it.
>>>>>
>>>>> -Adrian

[Bruno Busco]

Looking better into OFBiz I found a functionality similar to what I was
looking for in this screen:
https://demo.hotwaxmedia.com/ordermgr/control/searchorders

here for each row in the list there is a checkbox and then there is a combo
to select one action to perform on the selected items.
I tryed to study it to see if a common pattern could be derived from it but
I have seen that it is based on FTL only and no multi form as I was
suggested. May be this is because this has been developed some time ago.
Are you aware of some other parts of OfBiz where a multi form with action on
selected item is?

Many thanks,
Bruno

2008/7/9 Anil Patel <anil.patel@...>:

> Yes.
>
> Regards
> Anil Patel
>
>
> On Jul 9, 2008, at 1:38 PM, Adrian Crum wrote:
>
>  Anil,
>>
>> I think I found what you are talking about -
>>
>> http://developers.sun.com/portalserver/reference/techart/jsr168/
>>
>> Is that correct?
>>
>> -Adrian
>>
>> Anil Patel wrote:
>>
>>> I did not understand how  "Apache Directory" is more appropriate.
>>> What I mean is, There is UI behavior improvements that can be implemented
>>> in ofbiz. Significant chunk of it comes as part of Portal server
>>> implementation. Like its will be lot nicer if we did "Party Profile" type
>>> page in Portal.  Ofbiz Portlets "which is something similar to ofbiz
>>> screenlets" be lot more Portable in enterprise. Like we will be able to
>>> deliver them thru any other standard compliant Portal Server.
>>> Regards
>>> Anil Patel
>>> On Jul 8, 2008, at 1:07 PM, Adrian Crum wrote:
>>>
>>>> An interesting idea, but it looks like it overlaps a lot of the OFBiz
>>>> framework. I believe Apache Directory would be be more appropriate.
>>>>
>>>> -Adrian
>>>>
>>>> Anil Patel wrote:
>>>>
>>>>> Sometime back I discussed similar things with Andrew and Tim at that
>>>>> time they suggested to instead integrate Portal server into Ofbiz and have
>>>>> portal server manage all that. I liked it because then we are more in line
>>>>> with industry standards.
>>>>> Regards
>>>>> Anil Patel
>>>>> On Jul 8, 2008, at 11:31 AM, Adrian Crum wrote:
>>>>>
>>>>>> Hans Bakker wrote:
>>>>>>
>>>>>>> talking about preferences feature...wouldn't it be nice if the
>>>>>>> screenlet
>>>>>>> collapse is automatically remembered per user......
>>>>>>>
>>>>>>
>>>>>> It depends upon the screenlet. In some cases that might be unexpected
>>>>>> behavior. In other words, users might expect a screenlet to be expanded
>>>>>> until they collapse it.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>
>

[Jacopo Cappellato-3]

Maybe there is some example around.
However, off the top of my head, I don't think there is full support  
for this, but you can achieve a similar goal with some hack:

* define a multi form
* add to it, for each of the actions you want to trigger, a "button"  
link with a JavaScript action (using the form widget's action and  
event attributes) that just changes the target of the form and submits  
it

This is an hack, but it could be the first step to start to test the  
system (consider it a prototype); then we may consider what kind