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...
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3996454#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...