|
 
The InstantService in-house admin system is used by InstantService support folks
to create accounts, configure optional features, manage the chat servers
and generally keep things running. This project was a teardown, where I replaced
an existing system that had become outmoded and difficult to maintain. I got
to do just about the whole thing on this one, it was fun.
Click on an image below to see a full-size version in a new window.
I did all the graphics for the site, and there's definitely some sort of gear theme
going on. Don't ask me why, I don't normally think of myself as a gear person.
I had this bad moment in high school auto shop where I had
a handful of needle bearings left over after rebuilding a transmission and asked my
teacher what I should do with them. Wonder if that Chevy's still running?
Here's the home portal. True to form, I used little photos as icons on the site.
Hey, there's another gear. The site uses the same navigational framework as
account admin, in fact in-house admin is implemented as a private brand with an extra
security wrapper. The links to other resources are to other stand-alone
system management and tech support tools.
The account search page is where you can track down an account by a unique ID or by
the company name. Once you find the account, you can modify properties, like
connection types, optional features, custom links. I had fun building the
paging code used here. I wanted to use the original code for the system, since
it looked really complex and intricate and I didn't want to have to redo it all.
But I had such a hard time wading through the code that I decided to try doing it
myself. Mine ended up really simple, just four little methods inside one servlet
that took a day to write. I felt sort of bad about tossing out the original,
since there was obviously a lot of work that went into making it, but then thought
about having to maintain it forever and decided to keep the one that was easiest
to fix.
The optional features screen is where special extra-cost features are turned on or off
for an account. This is a new screen in the application; before these things
were all jumbled in with other stuff.
The broadcast screen is used by system managers when they're doing maintenance on the
system. They might need to take down a chat server for some reason; we'll warn
our customers well ahead of time, but as the moment approaches, they can broadcast a
message to anyone still logged in. There's some complex selection possibilities
available here; the idea is to be able to narrow down the user community that receives
a broadcast message.
The chat servers portal is a bit unusual. It has links and short descriptions,
like you'd expect from a portal page, but also displays chat server status right
there on the first screen in the section. The system managers requested this;
they wanted an indicator that told at a glance the state of the chat servers.
The links in the chat server status box go to a properties screen where some
configuration values for an individual chat server can be set.
The account list is one of several screens from our chat server metrics. These
modules display real-time data from a selected chat server. One of the other
engineers wrote the metrics code, I came up with the UI wrapper for it.
The chat server metrics can also be run independently of in-house admin.
This particular screen shows accounts active on a selected chat server, other
metrics display information about agents, customers, memory usage and other
real-time values.
|
This was a fun project to work on. I got to do graphic design, database work,
write Java servlets, build the static prototype, and basically wear a whole lot
of different hats. It's not that often when working on big web systems that
you get to do the whole thing yourself.
So what's a static prototype?
When you're building a big web system, there's sort of two major parts of it. Well,
there's a lot of major parts, but we'll just talk about these two. One part is
the way the user works with the system, the user interface. This has lots of
different elements: navigation, graphics, layout, font and so on. The other
major part of the system is what it does, how it works, how such-and-such a value is
saved to the database, that sort of thing. The "business end" of the
system.
A static prototype lets you mockup the user interface part of the system into a
"pretend" system you can click your way through, but that doesn't really
do anything. Once you get the static prototype done, you turn users loose to
play with it for a couple days, then they tell you all the things you goofed up on
or forgot about. This is great because it means that you learn about all
this stuff before you go to all the work of building the business end of the system.
Static prototypes work especially great for web systems because you can mock them
up in HTML. If you create the stylesheets and work with a consistent coding
style when you create the prototype, it's easy to evolve them into the
JSP pages or XML templates that make the final system go. But
they're also a good idea for applets or client-server VBA applications or whatever,
even if you have to throw away the mockup. Even (especially) if you need
to throw away a couple of mockups until you get things right. What you're
after is to get the surface-level user interaction parts of the system figured
out before you build the final version of something complicated, expensive and wrong.
InstantService is an application service provider in downtown Seattle.
The company has customers, sales, a growing business, and a good reputation.
|
