It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,789
×10,908
×3,952

question asked: Aug 07 '14, 7:39 a.m.
question was seen: 2,082 times
last updated: Aug 07 '14, 9:20 a.m.

Related questions

FAQ - How this Forum works

Why is the look-and-feel of Jazz applications different on their web interface?

0
Frank Schophuizen (193●2●32●26) | asked Aug 07 '14, 7:39 a.m.
The Jazz platform is an integrated set of applications built from scratch, not as the result of acquisitions and integrations of different tools. Yet, even within the CLM suite, RTC, RRC and RQM have a complete different look-and-feel. Why?

A few examples:
  • A work item in RTC (web interface) has a header (e.g. "Task 12345") at the left and action buttons on the right, then a Summary field and then a line of tabs to distinguish various sections ("Overview", "Links", "Approval", "History"). Within a tab, the are blocks of information with a grey headerline. On the right there is a (small) column with quick information. To edit you just type ahead and press "Save" to save. There is no cancel button; you need refresh to discard the changes.
  • A requirements specification in RRC/DOORS NG (also web interface) has a header (e.g. "7654: Customer Requirements") at the left and action buttons on the right, but it looks completely different. There is a 3 column layout. The left column contains actions ("Add Artifact") and various viewing/filtering sections, the middle contains the content and at the right there is metadata about the artifact (e.g. description, project, creation/modification data). To edit, you need to press the "Edit" button and finish with "Done" or "Cancel".
  • A test plan in RQM again looks completely different. The header (with title and action buttons) looks the same as RTC and RRC, except there is now a "Cancel" to discard changes. On the left there is a column with sections (comparable with the tabs in RTC) and the blocks of information have blue orders. To edit a box you need to press "Edit" and finish with "Save" or "Cancel".
  • A test case look similar to a test plan, but a test script does not use the blue-bordered boxes.

This may seem trivial or a matter of taste but I have heard many complaints about Jazz (actually CLM) that it is "too complicated", "steep learning curve" and "we cannot work with it". I have seen managers move away from Jazz for that reason.

Question: Jazz teams, can you please make the look-and-feel the same across the Jazz applications

Accepted answer

0
permanent link
Daniel Moul (4.9k●13●18) | answered Aug 07 '14, 8:22 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
Let's categorize these UI differences into two kinds:
1. Differences in the UIs due to differences in the kinds of artifacts the tools provide and how users interact with them
2. Differences with no inherent benefit

I think (1) is quite important and appropriate. We want users to be highly productive in their day-to-day work, and that means optimizing for their work flow and the information they need to accomplish it.  And there is more we can do to help users (especially new users) through their learning curve (tacking the complexity).

I agree that there is no valid reason for (2), and the user experience (UX) team have worked to narrow these differences over time.  As we continue to evolve the UIs we must also take into account the current user community and their familiarity with "How it works now".

Last, without diminishing the value of your statement and request, let me mention that we sometimes hear the opposite, along the lines of "The UIs of the CLM tools are too similar, and it's hard to keep track of which tool I'm in"  -- which just goes to show you can't satisfy everyone all the time.

Frank Schophuizen selected this answer as the correct answer
Comments
Frank Schophuizen commented Aug 07 '14, 9:19 a.m. | edited Aug 07 '14, 9:20 a.m.

You're right. Application (or domain) specifics needs to remain specific (cat 1).

Funny you take the example of "not knowing in which tool you are". I am under the impression that it is an ultimate goal of in-context collaboration to be transparent. OSLC defines delegated editing to allow editing of foreign data without leaving the context of the current tool.

The fact that users get familiar with UI differences which makes it harder to change the UIs, is precisely the reasons I am surprised that the those differences are not ruled out much earlier.

Anyway, thanks to reassuring me that this issue is being looked into.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.