Observation 1: Lack of any "call to action" is the main problem with this view because it violates the recognition rather than recall heuristic. This screen shows a navigation tool (tree) but with an empty content area. Most applications, online or otherwise, will present some form of content, even at the root view, because users are content oriented rather than navigation oriented.
Recommendation 1: If no meaningful content is available or appropriate, often times navigation will simply be repeated in some subtly different way in the content area. Since most users are accustom accustomed to navigating content anyway, thanks to Google and Yahoo, this approach presents the user with a meaningful "call to action" in a central part of the screen.
Observation 2: Another violation has to do with consistency and standards. While arrows have some conventionality to them, folders have more. Also, folders might be more appropriate since they are used in other uPortal UI's and in general are more meaningful in communicating categories.
Recommendation 2: Swap arrows for a more conventional folder icon in the tree.
Observation 3: The search tool appears to be unnecessarily complicated and therefore violates the Aesthetic aesthetic and minimalist design principle. The secondary selector option that specifies "whose name - contains, etc..." can likely be handled transparently by the system.
Recommendation 3: Lose that selector option. Perhaps lose the main selector (channel, group, person, etc.) also.
Observation 4: The search tool saves the users previous searches as "Search Results" in the tree, but does not display any metadata describing what the searches were for. This violates the recognition rather than recall principle.
Recommendation 4: Display the term which was searched for in the label. E.g. "Search for 'weather'."
Observation 5: Displaying the search results in the same tree as the categories violates the match between the system and the real world principle. It may even be confusing to group the portlet categories and the user types together in the same tree.
Recommendation 5: Separate the different types of items currently in the tree in some fashion, perhaps by using tabs so they are differentiated visually from the other only indirectly related items. Again, user research should be performed to determine whether users actually need to see the different types of items at once – if so, it may be best not to use tabs so they remain on the same page.
Observation 6: Prominently displaying all the user's searches in a session, if they are not frequently referred to, violates the aesthetic and minimalist design principle.
Recommendation 6: Perform user research to determine how frequently search results are used. If not used at all, remove from the interface. If used infrequently, consider making them less prominent or moving to another page with a link from the current page. If used frequently, separate them in some fashion so they don't appear to be part of the same tree as other only indirectly related items.
Observation 7: The "Delete Group" icon is dangerously close to the "Close Group" icon, and isn't differentiated enough visually from it. This violates the prevent errors heuristic.
Recommendation 7: Move the icons so there is some space between them. Add color to the icons to further differentiate them visually. In general in the application the icons should also be moved closer to the items they act on. | 
