Currently many "clickable" icons and text areas of the UI are counter intuitive to a point that they are most likely not to be noticed at all. One way or another (embedded UI documentation and/or standardized scheme) this should be resolved for the adopters to fully leverage Matterhorn capabilities.
Attaching some highlighted examples of such "hidden" clickable areas.
As for that first attachment:
Please keep in mind that the admin UI was originally designed primarily for relatively non-technical program administrators.
The original design goal was to keep the UI relatively clutter free for this primary user, but (until we came up with the UI for more technical operators and system administrator) make some of the features needed for those who are more technical available through subtle, non-cluttering "advanced" menus. The gear icon was supposed to be used like this (not quite as hidden as it was implemented): https://opencast.jira.com/wiki/display/MH/Integration+of+job+performance+charts+for+MH-5516 (with the thought that add'l items would be added to the menu). If we put all functionality (that any user could possibly want) front and center, we're going to end up with something that's not very usable for anybody. "Design for everyone and you design for no one".
I understand that operators have huge needs that nobody designed for, but as we proceed with UI changes can we at least keep in mind how they will affect relatively non-technical program administrators (since we have no alternative UI for them, since their UI was "hijacked")?
I understand how hard keeping things as simple as possible is, but as that famous guy said "Everything Should Be Made as Simple as Possible, But Not Simpler".
In the "hidden link" case I'm presenting I'm pretty sure the "hidden links" affects technical as much as non technical folks. As a matter of fact I wonder what "relatively non technical program administrator" means, since, for instance, the gear link takes you to a place where you can actually download playable media by means of another click.
Maybe we could poll since I don't think we have full UX resources to do real testing?
In any case a trick I have seen used in many applications is a small question mark icon that expands when you click it and explains the UI option next to it. This would be a quick, simple, but more importantly consistent way of presenting "clickable" areas. Basically where the user (technical or not) sees a question mark he will know there is something. Such a simple add on does not clutter the UI because there is actually nothing added in terms of functionality, just embedded documentation and navigation standardization.
At the end of the day I'm not so much asking for "advanced" menus as I am for a standardized UI where, for example, I know just by looking at a page what's an hyperlink and what's plain text. Certainly we have, thank $DEITY, standardized fields, drop down menus, and radio buttons, so I would argue hyperlinks/expandable areas should be standardized as well in the way they are presented.
I agree 100% that there shouldn't be links that look like plain text. You're seeing those on pages that were built by developers with no input from designers
I'm all for standardization, too, in principle. Just not overdoing it--I don't think you want to make every single thing on every page that's clickable look the same. Disclosure triangles, tabs, links, buttons, etc. are all "clickable" and users do realize they're clickable. If implemented correctly, the cursor changes, too, which alerts the user that something is clickable. Another best practice is having tool tips.
The small question mark that you're talking about sounds like contextual help, which is a great idea when documentation is needed, but it's not the right way to indicate that something is clickable. (Clutter the screen it will, if you place it next to everything on the page that's clickable.)
We got a new interface. If still an issue, please re-open.