console layout

[tom.baeyens]

i don't like the top level menu structure in http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsole

* Quick Links
* Deploy Process Definition
* Find Process Definition

i would prefer something like

* Tasks (personal and group tasks)
* Search (process executions, tasks, process definitions, ...)
* Statistics (all stats queries)
* Manage (deploy process definitions, ...)

What do you think of this alternative ?

[dmlloyd]

The thing that bothers me is that all the top level searches would then have a number of fields in common. I figured that upon locating a specific process definition, for example, one might want to then search for only process instances that are related to that definition.

The quick links thing grew out of an idea that the user could somehow add their own most common searches... but I'm not married to that idea.

Also, I put Deploy Process Definition at the top level because there are no other management functions that I know of (you have ... after it) :-)

Also, many of the stats queries depend on providing a process definition. So I thought it makes more sense, and would be simpler in any case, to provide these stats queries from a process definition page, where the user has already located the process definition and they want to find out more about it.

[tom.baeyens]

The thing that bothers me is that all the top level searches would then have a number of fields in common.

That is why i would put them on one page. On top you could have a radio button to specify what you're looking for: process definitions, process instances or tasks.

Then depending on that choice, you could enable/disable certain parts of the form to enter search criteria.

Also, I put Deploy Process Definition at the top level because there are no other management functions that I know of (you have ... after it) :-)

* (Re)binding process states to specific sub process definitions.
* Checking the size of the logs
* Migrating process instances or process definitions to another db
* Avg tx time
* ...

Currently, there are not many implemented, but this should definitely grow, i think. Keep in mind that all of these should also be exposed via the JBoss operations network.

Also, many of the stats queries depend on providing a process definition. So I thought it makes more sense, and would be simpler in any case, to provide these stats queries from a process definition page, where the user has already located the process definition and they want to find out more about it.

You could have one search page as described above. You might for instance start from that page and get a list of process definitions. Then for each process definition there might be a link called 'search process instances'. When clicking that link, you could navigate to that same search screen with process instances already selected as the items to search for and also the selected process definition prefilled in the criteria.

Is the idea clear ? I could sketch out something if that helps to get the picture.

What do you think of the idea ?

[dmlloyd]

That is why i would put them on one page. On top you could have a radio button to specify what you're looking for: process definitions, process instances or tasks.

You could have one search page as described above. You might for instance start from that page and get a list of process definitions. Then for each process definition there might be a link called 'search process instances'. When clicking that link, you could navigate to that same search screen with process instances already selected as the items to search for and also the selected process definition prefilled in the criteria.

Well I guess that is assuming that the process name, and I guess version, is enough to uniquely identify a process definition, but that doesn't really seem to be the case from looking at the database schema. Or maybe there should be an ID field for each type of entity to search, so that a specific entity can be unambiguously selected. However, if for example you have the ID of a process instance, you don't need to also specify terms to select the process definition, so this would add the possibility for several different combinations of invalid search criteria.

Also, I don't like the idea of one big search page, just because it's either going to be somewhat to implement (lots of javascript), or complex for the users to use (think bugzilla's massive ugly search page), or possibly both (either way we're talking much more complex queries). To me, a list of radio buttons with javascript to modify the search page is no better than separate links going to separate pages. If it were purely a question of reusing HTML, I could just compose pages using the facelets templating stuff. I'm really concerned that the queries will become more complex to build and test, and slower to execute, as the number of joined tables increases.

By having separate seach pages that work from the context of a single parent object, the queries can be simplified to search a much smaller set of tables. For example, "from ProcessInstance where processDefinition = :defId and startDate = :start" rather than "from ProcessInstance pi inner join pi.processDefinition pd where pd.name like :name and pd.version = :version and pi.startDate = :start".

In general my philosophy is: the simpler, the better.

Does this make sense?

* (Re)binding process states to specific sub process definitions.
* Checking the size of the logs
* Migrating process instances or process definitions to another db
* Avg tx time
* ...

Ok, that's fair, I did not know about those.

[tom.baeyens]

To me, a list of radio buttons with javascript to modify the search page is no better than separate links going to separate pages.

i think that one page will be simpler to accomodate all the different possible combinations that people could query for.

with separate links, you'll get an exponential number of separate pages to accomodate for all the different combinations of search criteria.

i also think that the complete page will not be that big

i also think that a single page will be simpler for users as they will recognize that page and not get lost in a tree of search pages.

[dmlloyd]

i think that one page will be simpler to accomodate all the different possible combinations that people could query for.

Maybe, but again the end result is more complex (and slower) queries.

with separate links, you'll get an exponential number of separate pages to accomodate for all the different combinations of search criteria.

You get that with radio buttons too. The only difference is that you're using javascript to generate all the different combinations. You still have to handle all the criteria on the server side. Also, the problem stands that prepopulating the search form may not be sufficient to uniquely select the item in question.

i also think that the complete page will not be that big.

i also think that a single page will be simpler for users as they will recognize that page and not get lost in a tree of search pages.

That is true, but it might be made less confusing by designing the UI such that the user is never really "lost". I think that clear navigation controls can help a lot with this.