uP2 Fragment Manager Heuristic Analysis

Obscure access to the functionality
The fragment manager is located under the User Preferences umbrella, which does not match real world conventions and forces recall instead of recognition by hiding it under several non-intuitive layers. Managing and publishing fragments is a community content management function not a user preference function, and is not logically grouped with functions affecting personal layout.

The label Fragment is unclear
Fragment is a non-standard term for grouped content. It may be that Fragment is now a conventional term to the uPortal community, but everyone would benefit from using a clearer label. The term Fragment also carries a negative undertone as the definition of fragment implies incompleteness or even brokeness.

Singular folder icon is confusing
Tree/folder hierarchy is commonplace and conventional, but this navigation and interface is confusing by showing only one, solitary folder with no ability to expand/collapse the folder, and no obvious means for managing the hierarchy (add, edit, delet folders). It also is unnecessary to display the root node, as the user is already in the Fragments context.

Inconsistent edit mode
All of the fragment actions (create new, (edit) fragment properties, publish fragment, delete fragment) happen in the same interface, with the exception of edit content, which removes the user from the fragment manager context.

Overuse of the label
This (edit) framgent propreties view would be equally as useful and probably more efficient without the overuse of the fragment label as the user is already in the fragment management context (view title is Fragment Management: Admin Tools properties).

Erroneous directions
This declaration of action to the user in the create new fragment view is erroneous and confusing.

Users are allowed to create fragments with no name
Users should be prevented from creating this problem and having to sort through esoteric naming (id:23)

System-oriented terminology is confusing
Users should be given communication in the human context, not the system context (e.g., "fragment root". In this case, the entire line and checkbox (Add a content container to the new fragment root (recommended)) should be removed from the interface and processed automatically by the system.

No help
There is no help available.