[kbarfield]

David,

I pulled down the latest code from head (12/4), and I'm finding the new menus and functionality flow to be very unituitive. I can't make heads or tails of what I am supposed to do. At this point, I want to take a step back and understand what functions we are expecting jBPM end users to do with the web console, and what functions we are expecting jBPM admins to do with the web console. In my mind, there should be almost no menus for jBPM end users, and very minimal ones for admins. Please help me understand where we are going here, and maybe I can help out with some testing and some ideas.

Also, please understand I'm not trying to beat up your work on the console. I just want the end product to be very easy to use for jBPM developers, admins, and users.

Thanks,

Kevin

[kukeltje]

The introduction of the tabs are working nice for me. compliments.

Some small issues: I'd put the summary as the last tab, or at least not the first. The taskform should be the first imo.

Anther small issue (probably because things are under development) is that the 'do it' in the task list and the summary in the pocess list both refere to a different (non existing) summary.jsf/xhtml page. Also the instance view menu item (under the process) referes to a non existing page. Again, both probably because things are under development, but i thought I'd mention them anyway

[falazar]

We've done a lot of work on the JBPM console over the past few months, making it look a little nicer and be a little more functional, so I think some of this work might be taken into account and incorperated into the system as there are some useful bits.

Here is a copy of the presentation we gave last week to our system admins locally, showing many screenshots of the system and how it works, maybe this will help show some things that are useful in the console design.

ftp://ftp.arlut.utexas.edu/pub/workflow/workflow_talk.pdf


One thing we noticed was there was a need for a more complex display of the Tasks to the lowest level user.
We added in sorting, and filtering, and paging for the processes, but due to the complex nature of the queries we could not use the HQL in an easy fashion and finally just generated a strait SQL query instead.
We display the process name, and 3 extra process variables in the display, and are looking at making special displays when 'filter by process' is used to show some other important variables.

We have focused much of the work on the end users display and not alot so far into the admin portion. But we have kept hte menu system very simple, opting for mainly a top 'tab' liek structure, and leaving hte sidebar off, due to the large size of many of the rows of data.

We haven't yet really used any fancy JSF components, just a dataTable for the display.

Any suggestions to our design would be great as well.

James Ratcliff & Jonathan Abbey

[kukeltje]

David,

Again, compliments for combining the search functionality in the table. I'm sure Gavin would like to have this in seam as well for other lists besides tasklists (I would). (There is a Jira issue for seam on this, if it could be made more generic... that would be great)

Some remarks still...

- The opening page is the user tasklist. That is (obivious) the most important one. I therefor would make it, the user part of the menu, the top one in the menu. (the username and logout are probably out of place then... hmmmmm)
- There is some inconsitency in the menu vs the title of the page (find processes in the menu vs start process in the page)
- Make the menu higlight the 'current/active' page
- I (personally) dislike 'jumping' screens and/or menus. The error reports should imo be in a place that does not make the screen jump.

I agree with James (and Jonathan) that some kind of grouping (like a tree table does) would be nice to have the tasks grouped by the first specified colum (i'd hide the id and have the 'view' either in the end or make the row itself clickable (with e.g. a tooltip which tells this to the user). You can then group by e.g. the process name, or the taskname (in which case this should (imo) not be tasks with the same name over processes with different names).

Ok, besides this (imo ;-) ) constructive critisism, some nitpicking. The grey is a little dark, shouldn't we use the grey from the jboss site? That is a little lighter.

And to James, did you see the latest jbpm search for tables... it's great... Now if only it would be shown as what it is in the exadel jsf editor... (ahhh well, I've got to have something to dream about, other then.......)

[kukeltje]

some other comments:
- I expected the task I'm in to be highlighted when I opened the diagram. It isn't, while it is when you go to the process instance and look at the diagram. Is that on purpose?
- The task instance definition is imo not realy usefull. Two of the three tabs are already in the instance menu/tabs only the summary is a little different. Besides that I do not know how to access the task definition if I'm in a process definition page. Maybe that page should contain a tab 'tasks' with a list of the defined tasks and the sub tabs that are now in the page you go to from task definition menu item.

I have this feeling that the task instance should have a tab 'process instance' instead of the generic 'process instance' menu item, but I'm not sure. Do I make sense? Talk non-sense? .....

[kukeltje]

hmmm... I keep posting... :-)

I'd hide the complete table of tasks etc if there are no initial tasks found (not after filtering).

And I'd make it optional to show the filters/search by e.g. adding magnifying glass icon in the bar with the next/prev so it can be turned on/off.... Again, all this not dedicated to jBPM, but with seam et al in mind as well..

[dmlloyd]

Responding to the oldest post first....

"kbarfield" wrote:
I pulled down the latest code from head (12/4), and I'm finding the new menus and functionality flow to be very unituitive. I can't make heads or tails of what I am supposed to do. At this point, I want to take a step back and understand what functions we are expecting jBPM end users to do with the web console, and what functions we are expecting jBPM admins to do with the web console. In my mind, there should be almost no menus for jBPM end users, and very minimal ones for admins. Please help me understand where we are going here, and maybe I can help out with some testing and some ideas.

Currently the navigation flow has taken a backseat to content. The current content is sort of a mishmash of functionality that is useful to different parties; some admin functions, some manager functions, and some end-user functions. I definitely plan to organize the content before the final release.

"kbarfield" wrote:
Also, please understand I'm not trying to beat up your work on the console. I just want the end product to be very easy to use for jBPM developers, admins, and users.

No worries, thanks for the feedback.

"kukeltje" wrote:
The introduction of the tabs are working nice for me. compliments.

Some small issues: I'd put the summary as the last tab, or at least not the first. The taskform should be the first imo.

I put the summary tab first because it's always guaranteed to work. For example, it makes little sense to display the task form for a task that is complete. I think that for a user's view though, it might make more sense to have the task form be the default, and maybe do something navigationally to prevent a user from navigating to a closed task.

"kukeltje" wrote:
Anther small issue (probably because things are under development) is that the 'do it' in the task list and the summary in the pocess list both refere to a different (non existing) summary.jsf/xhtml page. Also the instance view menu item (under the process) referes to a non existing page. Again, both probably because things are under development, but i thought I'd mention them anyway.

This is fixed in the latest CVS, as you've probably discovered by now...

"falazar" wrote:
We've done a lot of work on the JBPM console over the past few months, making it look a little nicer and be a little more functional, so I think some of this work might be taken into account and incorperated into the system as there are some useful bits.

Here is a copy of the presentation we gave last week to our system admins locally, showing many screenshots of the system and how it works, maybe this will help show some things that are useful in the console design.

ftp://ftp.arlut.utexas.edu/pub/workflow/workflow_talk.pdf

One thing we noticed was there was a need for a more complex display of the Tasks to the lowest level user.
We added in sorting, and filtering, and paging for the processes, but due to the complex nature of the queries we could not use the HQL in an easy fashion and finally just generated a strait SQL query instead.
We display the process name, and 3 extra process variables in the display, and are looking at making special displays when 'filter by process' is used to show some other important variables.

The current web console source has filtering (it is accomplished by using Hibernate criteria queries). Sorting will be added at some point in the future. Feel free to use whatever you'd think is helpful (under the terms of the license of course). What might (or might not) be of interest to you is the jbpm:dataTable component, which supports multiple row and column groups (this is how we get the search filter to display below the headings but above the results).

"kukeltje" wrote:
The opening page is the user tasklist. That is (obivious) the most important one. I therefor would make it, the user part of the menu, the top one in the menu. (the username and logout are probably out of place then... hmmmmm)

Yeah, this occured to me too, but I didn't have a quick answer so I just tabled the thought. One thing that has occured to me in the past is that the view that is currently presented (of the user task list) is more of a managerial view. I think I will ultimately end up making another user task list which is only the current user, and renaming the current one to be "All Tasks" or something to that effect.

"kukeltje" wrote:
There is some inconsitency in the menu vs the title of the page (find processes in the menu vs start process in the page)

Ah yes, I forgot about that one, I'll fix it today.

"kukeltje" wrote:
Make the menu higlight the 'current/active' page

I'll make a note of this, but I'm inclined not to bother until navigation is finalized.

"kukeltje" wrote:
I (personally) dislike 'jumping' screens and/or menus. The error reports should imo be in a place that does not make the screen jump.

I could put it in the blank area above, but in order to definitely prevent jumping, it would have to scroll when the content is too large to fit in that area. So the question is, what is worse? Jumping or scrolling?

"kukeltje" wrote:
I agree with James (and Jonathan) that some kind of grouping (like a tree table does) would be nice to have the tasks grouped by the first specified colum (i'd hide the id and have the 'view' either in the end or make the row itself clickable (with e.g. a tooltip which tells this to the user). You can then group by e.g. the process name, or the taskname (in which case this should (imo) not be tasks with the same name over processes with different names).

I can't guarantee that this will be a priority for 3.2.0, but I'll make a note of it for future releases in the 3.2.x series, at least. I think sorting will achieve this goal as well.

"kukeltje" wrote:
Ok, besides this (imo ;-) ) constructive critisism, some nitpicking. The grey is a little dark, shouldn't we use the grey from the jboss site? That is a little lighter.

Sure. :-) You mean the grey that's inside the table cells, right?

"kukeltje" wrote:
And to James, did you see the latest jbpm search for tables... it's great... Now if only it would be shown as what it is in the exadel jsf editor... (ahhh well, I've got to have something to dream about, other then.......)

This is likely due to the fact that the search tables use a customized dataTable component. The reason for this is that the standard dataTable only supports a single row group, whereas mine supports multiple row and column groups, which makes a bunch of things possible that are not possible with the standard component.

"kukeltje" wrote:
I expected the task I'm in to be highlighted when I opened the diagram. It isn't, while it is when you go to the process instance and look at the diagram. Is that on purpose?

This is a known bug: http://jira.jboss.com/jira/browse/JBPM-795

"kukeltje" wrote:
The task instance definition is imo not realy usefull. Two of the three tabs are already in the instance menu/tabs only the summary is a little different. Besides that I do not know how to access the task definition if I'm in a process definition page. Maybe that page should contain a tab 'tasks' with a list of the defined tasks and the sub tabs that are now in the page you go to from task definition menu item.

I'll be sure to address this after we asses the application navigation. I came to a similar conclusion when looking at the different content. It occurred to me that when someone is looking at a task instance, they may wish to see task definition information, and having to switch menu items is a bit clumsy.

"kukeltje" wrote:
I have this feeling that the task instance should have a tab 'process instance' instead of the generic 'process instance' menu item, but I'm not sure. Do I make sense? Talk non-sense?

No, you may be on to something there. I'll keep it in mind.

"kukeltje" wrote:
I'd hide the complete table of tasks etc if there are no initial tasks found (not after filtering).

Maybe. That may not be enough of a benefit vs. time to implement though. :-)

"kukeltje" wrote:
And I'd make it optional to show the filters/search by e.g. adding magnifying glass icon in the bar with the next/prev so it can be turned on/off.... Again, all this not dedicated to jBPM, but with seam et al in mind as well..

Hmmm, maybe...

[kukeltje]

Great, thanks for the feedback on the feedback.

I'll think about some generic mechanism for highlighting the current menu item in relation to the page. We need this in our company as well, and for the seam-gen pages it would be cool to.

Maybe some small javascript wrapped in a jbpm:higlightmenu tag that takes an id as a param and sets the class of that id to something different. Should not be to difficult I guess. You just have to explicitly assign id's to menuitems.... This way the navigation does not realy influence the menu (at least not the highlighting)

ohhh and yes, I meant the grey in the menu... (are they tables? Maybe a UL/LI is easier to read in the code...

[dmlloyd]

"kukeltje" wrote:
Great, thanks for the feedback on the feedback.

I'll think about some generic mechanism for highlighting the current menu item in relation to the page. We need this in our company as well, and for the seam-gen pages it would be cool to.

Maybe some small javascript wrapped in a jbpm:higlightmenu tag that takes an id as a param and sets the class of that id to something different. Should not be to difficult I guess. You just have to explicitly assign id's to menuitems.... This way the navigation does not realy influence the menu (at least not the highlighting)

Yeah, the main issue I had was associating a screen with the menu item. I thought about perhaps using view ID for this purpose. I will think about this some more.

"kukeltje" wrote:
ohhh and yes, I meant the grey in the menu... (are they tables? Maybe a UL/LI is easier to read in the code...

Ah, no those don't use UL, they're just consecutive DIVs (well, also A and SPAN with display:block set on them). Changing them is as easy as changing the CSS.

[tom.baeyens]

I put the summary tab first because it's always guaranteed to work.

i think that the task form should always be shown first. optionally, you could add a switch that shows the summary if no form is available. but wait with updating this till the whole navigation feedback has been sorted out.

[falazar]

Correct, we go directly to the task form as well, without the summary form,
and as a whole it feels a little more complicated than necessary, I'm not sure if there are parts that will be removed for the low end user or not, we went with giving them few options as top level, only Inbox (personal and group tasks in two tabs)
Open Processes and Past Processes. Then the Manager pages and Admin pages would have other options available.
I posted a PDF presentation we gave, that had some of the screen shots in another topic if anyone would like to comment.

[falazar]

"kukeltje" wrote:
The opening page is the user tasklist. That is (obivious) the most important one. I therefor would make it, the user part of the menu, the top one in the menu. (the username and logout are probably out of place then... hmmmmm)

David:
Yeah, this occured to me too, but I didn't have a quick answer so I just tabled the thought. One thing that has occured to me in the past is that the view that is currently presented (of the user task list) is more of a managerial view. I think I will ultimately end up making another user task list which is only the current user, and renaming the current one to be "All Tasks" or something to that effect.

Falazar:
Yeah right now the first thing on the menu is inactive most of the time, and jumps around, I would rather see the main (bottom) stuff up top, and we made and All Tasks page like that, and a Users task page as well, that are seperate.

Also we are working now on a scheme that would allow a special "filtered" view for process lists or task lists, that would show certain process varaibles, that are deemed "important" this was suggested for several things like "Purchase Requests" where the Amount was wanted to be seen in the list view.