revolution for my group began a few years ago when we redesigned the
user interface for the SAN Volume Controller storage device using an
iterative process (sometimes called Agile). Instead of designing
everything up front and driving the development activity as a single
effort, we broke it up into smaller time-boxed chunks. These chunks
gave us the opportunity to start showing the progress of the GUI to our
stakeholders, get some feedback, and then incorporate it into the next
iteration. In this way we gained a level of flexibility we just did not
Let's flash forward to today where the
process has matured quite a bit. Instead of a few IBMers providing
feedback, we now collect feedback from a wide range of stakeholders --
developers, product management, customer facing IBMers and end-users as
well. We've invited these stakeholders into the design process, even
before we've written a single line of code, to collect requirements and
build relationships that are needed during the entire design and
development cycle. In my previous blog, I outlined a few ways that
we're engaging end-users into our development effort. We definitely
would love for you to join us in making the user experience for TSM
A good example of this effect is a recent trip
I made to Baltimore. I went there to talk to the semi-annual Tivoli
User Group about our new GUI. We had a great audience with over 50
people from many walks of life -- long time TSM administrators, business
partners and a few IBMers. During the meeting, we went over the
roadmap and gave a demo of the current development iteration. I love
the feedback we get from these sessions; there's just so much enthusiasm
in the TSM user community, it's hard not to get carried away by it.
Based on feedback from the user meeting, I've already been in contact
with development and product management teams to prioritise and work in
the feedback into our ongoing activity.
Along with the
iterative development revolution, we have also changed our focus.
We've recognised that the best feature or function is ultimately useless
to you if it is not easy to use. With increased pressure on IT staff,
there just isn't the free time available any longer to learn new
features or capabilities. The burden is on us, in development, to make
the features consumable with minimal training and up front training.
reminded of a discussion I had with a TPC customer earlier in the
year. We'd just completed the new design of the user interface and the
customer was pleased that the product contained a new feature. The only
thing is, this new feature had existed in the product for a few years
-- but was so difficult to find that the user never even knew it was
there. Sometimes making a feature usable is just as effective as making
the feature itself.
The goals for the TSM user
interface are pretty straight forward -- intuitive and easy-to-use,
improved signal-to-noise, and visually attractive and modern:
and easy-to-use means that the product must have simplified task flows
that reduce the ramp-up time for first-time and occasional users while
still maintaining the high degree of capability that TSM is known for.
Within the development team, we created a motto to underscore the need
for ease-of-use -- "
Maniacal Focus on Simplicity."
design team, the majority of our time is spent on making the panels as
simple as possible. An example of this is the overview page (you can
see a screenshot of it below). I've not gone back and counted them, but
feels like had almost ten major iterations of that panel to get it to
the state you see today. Each step moving us closer and closer to what
we hope will be an immediately intuitive diagram of the system state.
signal-to-noise means that information contained on the pages needs to
be relevant to the task you're working on. It is all too easy to
decorate a user interface with charts, graphs, and controls to the point
where you lose track of the original purpose of the page. This is
ultimately coupled with the simplicity goal in the first bullet. As we
iterate through, making things easier and easier, we're always having to
come back to the base question of "
what does the user do on this page"
and how we can align the data to directly serve those needs.
attractive and modern creates a good first impression that entices
users to try the new interface and then experience the full set of
capabilities. This is the most obvious element of the new GUI design,
but in some sense it's the least important. In the end, we will not
have met our objectives if we have a pretty but complex, or attractive
and useless GUI -- so this is a supporting characteristic, but by no
means is it sufficient.
Of course, we hope that we're
making positive progress towards these goals. I really don't know if we
can ever achieve them outright; it's a continuous process where we get
better step-by-step over time. I definitely want to hear from you -- as
I mentioned above, your feedback is a critical part of the process.
give you an idea of our progress, I've included a few screenshots of
the new user interface. As with everything in this blot, these
screenshots represent a work in progress, so please don't view them as a
commitment or view of final products.
is the first thing you see after logging into the GUI. Along the top
is a very simple menu bar showing the places you can go leaving the
majority of the workspace free for the content itself. The dashboard
itself is shown as a logical diagram showing how the clients interact
with the servers through a set of services. This helps orient new users
in the logical structure of TSM, while still providing needed status
information. Moving your mouse around the diagram reveals several live
elements that provide access to additional information -- for example,
the mockup shows the services pod highlighted in blue. A single mouse
click here will take you to the policy page.
Alerts List Page
next screenshot is the alerts list page. You can get to it from the
alerts pod of the overview. Alerts are a new capability in TSM where it
will collect information from the activity log automatically and
highlight them in the table so you don't have to go looking for them.
The entries in the table can be assigned to TSM administrators, moved to
inactive state, or closed altogether. It's worthwhile to note that the
usability improvements we've made from the storage devices and TPC are
also present here -- for example, the columns are configurable (resize,
move, sort order and hide/unhide) and these changes are persistent. The
next time you come back to the page, you'll see the same table
configuration as you left it. This general structure is the same for
other assets -- such as TSM Servers, Clients, Storage Pools, Policies,
etc. Once you learn how the list page works for one asset, it's
immediately obvious how it works for any of the others.
Client Details Page
final example shows a page dedicated to the details of a specific
client. You can get here by drilling through a list of resources
(similar to the alert page, but showing all clients). The intent is to
holistically show everything about a the client from this single page to
minimise the number of page reloads -- just select the item on the left
to see the corresponding component view on the right.
with the list page above, we leverage this structure for all the basic
asset types. So you would see a very similar page layout for TSM
Servers and so forth.