Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

UI (User Interface) enhancements

Links in screenlets.

  • Have less (or even none) buttons in header
  • It was also suggesteed to use screenlet like how gmail does. Notably
    • Three buttons max
    • Dropdown for other actions
    • The idea of duplicating at bottom
  • Having breadcrumbs under the title bar
  • Using portlets in place of screenlets
  • Recently (12/08) I was discussed if we should remove the screenlet's navigation-form-name attribute. There are (at least) 3 reasons for that
    • Less informations/features than with default (pages numbers, ability to jump to any page)
    • The last button does not always work (try with widget.form.defaultViewSize=2 when listing invoices)
    • Pagination should be available to the user always in the same way in order to have a consistent UI.
      Then we have 2 possibilities
      1. Remove this attribute and all current uses.
      2. Keep it but then
        1. we should at least make it works (last button issue)
        2. make it consistent with the standard way (direct page access)

OFBiz Theme Gallery DONE

Visual Themes Gallery

Web tools

  • Entity Data maintenance
    • have vertical separators for columns when viewing entity content,
    • make the Find options a collapsible screenlet,
    • make styles of the Entity Data Maintenance screens in general the same than used by the widgets.
  • At large, maybe restyle all the Web tools page (not a priority)

Introduce Mashups

Example in OFBIZ-1873

List : to have in the results 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.

  • A mechanism to allow to collapse/uncollapse all fields in one click
  • Use the screenlet and put an icon (or a word, it's an icon in Compiere) in the screenlet title bar for that.
  • OR
  • Another (easier) possibility would be to use the 1st field-group and to make a relation between it and other field-groups. This because in all cases we will no make this 1st field-group collapsible (at least it's how we have done so far) and we could then put an artifact there. This would also allow to not have a mandatory screenlet when using collapsible field-groupsAllow to create a party from where it could be needed By putting

Applications Tabs

  • Sorting
    • The tabs should be sortable not only by alphabetical order in English but in other languages too.
    • An user should to be able to position the tabs according to their preference
  • Drop-down menus
    • We should introduce drop-down menus to group applications (like AR and AP under Accounting). Doint that, we should keep in mind permissions acces for each tab.
    • Replace the secondary menu (at bottom) with a primary menu top drop-down item.
    • Having something to select the apps desired for a "quick links" bar, and maybe have that go beyond just tabbed applications and include individual pages for easy access.

Quicker an intuitive access to basic functionnalities (creation, etc.)

Following Bruno's suggestion about Compiere UI. We could put a link to https://localhost:8443/partymgr/control/createnewImage Added everywhere we have a party lookup, using the party label at left of the field. Actually we could generalising everywhere we have a lookup for something.
It's easy to click on the Party tab and then on

...

"Create New". But after reading BJ's reading suggestion, it's also an easy way to teach newbies how to do it. Easy for us to introduce, and easy for newbies to use, maybe with a tooltip "click on party to create". This would fill the Condition #2 of the article above.
Of course being able to show the screen where the choice of the type of party to create is done, and then the screen where data are entered in a CSS hidden/shown window like the calendar would be great and could be our next target. This would allow to not leave the page the user is on and would create a less disturbing environment. But I know that this would also mean to preload these windows in memory and is maybe out of reach at the moment (from a memory POV, without speaking of the code needed). Else we could do the same thing for all the lookups, having them poping up as fast as the calendar. From a code POV, perhaps generalising from the calendar code could be a way (this last suggestion is more a dream for the future - sometimes not so far - than anything else) (smile)

...


For a first effort, it was suggested that tools tips that direct the user to the necessary steps would be sufficient. Like "create new ($whatever) by clicking on ($whatever1) tab and click on ($whatever2) link" could make the tooltip a template and ($whaterver1-2) is the only things that is a variable. Of course then you can enhance the tool tip to handle links. Then you could just modify the I8N files without touching code "Click here to ($whatever)"
The tooltips labels could be in there own file for an entity. A class that would bes similar to the one that maintains the DB tables can be hooked into Create of the file to add the tooltips. This could be set to defaults based on the Field type.
Now we have the ability to put parms into the label in the I8N files, so the tooltips would have the same ability. Like "Click here to ($whatever)" would turn into "Click here to see the productlist" as a tool tip. You would just have the fieldname like in the labels file.
Barring having a seperate file, then having the tooltip_$fieldname like tooltip_$Phonenumber would work

...

  • The tabs should be sortable not only by alphabetical order in English but in other languages too.
  • An user should to be able to position the tabs according to their preference

...

.