Entricom's entriNumber software was created to help CLECs and Telcos manage their telephone number resources.  This huge web-based application was developed in a great burst of activity by a feisty development team.  This was an all-new application for the company; I designed the page layout and first working prototypes, and developed many of the JSP pages and servlets. 

Click on an image below to see a full-size version in a new window.

This is the entriNumber home portal, showing all the modules available at the time.  There's a lot of stuff under the surface; some sections went several layers deep.  The left side navigation bar was built dynamically by a security-conscious Java module reading from an XML data store.  If the application looks structurally a bit like the Bahá'í Prayers website, it's intentional.  This model of dynamic navigation on the left, bold page titles and content pushed clear up to the top of the screen works well on sites with many pages of difficult material.

Here's a typical entriNumber screen; this one shows historical utilization of phone number resources.  The top frame in the content portion displays search criteria, the bottom shows results.  The links lead to edit panels.  There were dozens of screens structured like this, some with multiple edit parameters, a dozen search criteria, elaborate lateral navigation.

The block management portion of the application was intended for use by telecom companies who needed to allocate blocks of 1000 phone numbers at a time.  Various agencies keep track of which company has what numbers; phone numbers are something of a vanishing resource in this day of cell phones, modems and beepers.  Note that the left nav bar is collapsible down to the narrow configuration shown here.  This was needed due to some of the double-wide result sets returned in the search screens.

The subscription versions screen is something of a control panel.  Jeff Smith, one of the developers on our team, came up with this one.  The color-keyed buttons are intended to be easily recognized at a glance by someone who works with the screen all day every day.  The search criteria could be used to return arbitrary rows, and the operator was then able to apply changes to individual rows or to the collected result set. 

Forecasting was sort of the opposite of historical utilization.  The utilization screens told a carrier how many phone number resources had been used in the past; the forecast screens were predictive about future use. 

This is one of the formset screens, which allowed operators to compile the forms used to request phone number resources from oversight agencies.  Different forms were required for different situations, sort of like tax forms for the IRS.  The printable version buttons brought up PDF file recreations of paper forms with the values filled in.  The printable reports were one of my projects; I built them using a third-party Java class library designed for reporting.  I suppose it is somewhat telling of the telecom industry that a huge complex XML-based system capable of serializing and transmitting forecast data was instead used to generate paper forms that would be faxed to some poor clerk somewhere. 

The service provider area let carriers keep track of local phone service providers who share responsibility for customers, numbers, blocks or other resources.  This was another complex interface; in this case,a successful search displays an edit screen and several lateral property screens, navigable via the links near the top of the content area.  One of my regrets about this interface is we didn't have the time to develop breadcrumb navigation.  This would have been a helpful feature; it was easy to get really deep in the weeds.