Best way to implement a sparse set of UI pages with businees rules underneath?

The question is: Given the richness of Nuxeo's UI options what is the best approach to build a sparse set of UI pages using the information outlined below.

I have Nuxeo model (documents) built and have built many actions and document life cycles to manipulate the model based on business use cases.

I now have a requirement to display only the “necessary” data and information for a given use case. What is deemed necessary is bounded by a very specific set of use cases. Each of the use cases requires data entry, mostly boolean (yes/no), numbers both decimal and integer and an occasional image. My model nuxeo documents are all folderish so I have a place to but the images that might me entered.Bottom line is I need to create a limited number of options (use case based) for each screen. The “Standard Nuxeo UI” requires too many clicks to use for my use cases, since the use cases are fixed and repetitive following well defined business rules. Each page will only have one or two entries and a header that has context information for the specific job being worked. The UI's will be “task” driven based on the document's life cycle; as the users move through a given document's life cycle a group will be assigned specific, focused tasks with small amount of data entry and a GO/NOGO decision at the end of the screen.

I understand why the Standard UI is designed the way it is. This is not a criticism of the interface, I just need something that is focused and has almost no options other than the ones defined in the use cases. No navigation, no pull down options other than login/logout.

It seems the Nuxeo widgets should work fine I just need to take most of the standard nuxeo web layouts out and replace them with a greatly reduced (in size, not in number) set of layouts based on each specific use case.

Any other thoughts?

1 votes

2 answers

1994 views

ANSWER



I'm not sure to understand your need.

But if your need is to have the possibility to modify a document directly when you navigate in it, you can modify the first tab display to display only a form to modify the 2/3 metadata.

You can also have the possibility to display the list of document with an input text where the user can modify directly the document in the list.

I think you will have less code to produce than the GWT. To what I just explained before, you will have for the first point to create a new tab (a Nuxeo action + an xhtml fragment) or reuse the Edit tab resource (so only an action). The layout system is really powerful and authorize many things.

For the second point there will be a little bit more work (a bean that manage this view + a content view).

But as I'm not sure of the UI you are looking for, I'm not sure if what I just explain answer to you.

0 votes



From your reply my need is best described by your first point. A screen which is blank except for several labels(from metadata but no editing) and several metadata fields (editable). These metadata are based on the lifecycle of the document . Basically a simple data entry screen. The only navigation buttons will be a submit and pause button with other navigation options triggered based on the data entered (almost always boolean) into the editable fields.

So the need is to remove everything, tabs, navigation, worklist, clipboard, all icons, pull down's, etc, etc, from a screen and add back only a very small set of editable and non-editable metadata. These screens will change for different document lifecycle states so they need to be filtered.

I hope this clarifications helps with any suggestions you may have.

03/06/2012


I have built applications like this with a GWT (Google Web Toolkit) wrapper. Perfect for applications that only require a fraction of the functionality of the standard UI, and the learning curve for focused applications is much lower, adoption typically higher, and deployment easier. I also use GWT to tie in data to/from other sources (outside Nuxeo).

Of course if you haven't used GWT before there is a definite learning curve.

0 votes