Database Reference
In-Depth Information
A good GUI has, among other things, the following characteristics:
Clarity : It's easy to find what you want.
Consistency : Similar tasks are done in similar ways.
Efficiency : Tasks are quickly and easily achieved.
Grid Control was a letdown in all of these areas, primarily because of its interface design and poor navigation in
the product. The prime paradigm for the database pages was that of a categorized list of links. This led to a text-heavy
set of pages with links sometimes located in surprising places—for example, the AWR interface, which you might
expect to find on the Performance tab, was in fact located on the Server tab of the main database management screen.
Overall, the choice and layout of links was more reminiscent of small, community ad sites such as Craigslist rather
than a task-oriented management application.
This decision mattered, probably more than the designers imagined, because of the principle that a good UI
should be clear. The old Grid Control interface left even experienced hands at times clicking from tab to tab and link
to link, trying to find pages that they knew were listed somewhere. The product was also littered with odd artifacts that
were never really addressed; for example, the server management screen for databases had two distinct links labeled
JOBS that would take the user to separate pages, one for the database scheduler and one for the Enterprise Manager
scheduler. There was no link to the job scheduler with which most DBAs of the time were familiar, DBMS_JOB .
one particularly annoying aspect of the grid Control interface was the inconsistent arrangement of columns at
the bottom of each page. the columns were more or less common but arranged in a different order on each tab. thus the
location of the monitoring configuration link depended on which tab was active at the time.
Note
Second, the interface design was inconsistent between products. Switching from database to application server
management gave you whole new interface paradigms. For example, context menus appeared in parts of the product
but not others, and the plug-ins used to provide graphical displays were different. This inconsistency in appearance
and style actively hindered users familiar with one part of the product from finding the appropriate functionality
when they were required to manage a different technology with the product.
The following figures illustrate these problems well. Both are performance management pages, one for the
database and one for a J2EE application server, but they might as well come from different products. Figure 4-3
represents the current performance of a database instance. The page uses area charts extensively to represent CPU
and I/O load on the instance and to categorize current activity. By contrast, Figure 4-4 , which is the nearest equivalent
WebLogic page, primarily uses line charts to represent current activity, allows extensive customization of the
information presented, and has an entirely different look and feel. For administrators with responsibility for multiple
areas, this constant changing of interface actively interfered with the effectiveness with which they could operate.
 
 
Search WWH ::




Custom Search