CM: THE NEXT GENERATION of ALM Tool

GUI technology, using WxWidgets on Unix, very similar to MFC.  Still for other platforms, Neuma allowed for a Web-based client.  And for the most part, customization of the Web-based GUI and the native-based GUI were to be one and the same, or at least have that option.  In reality, Web-based GUIs tend to be much more focused than native GUIs, but that's all changing with HTML5.  So the new challenge is GUI device format (e.g. smartphone vs laptop).  This latter challenge is still being addressed.

To support data on all architectures, the STS Engine made sure that text files it read, such as scripts, could use any line ending mechanism, independent of the platform on which it resided or on which it was executed.  It also made sure that the line-end encoding was not part of the version manager (called the Source Manager, or SM).  So you can move files around without any issue with respect to line-end, and can retrieve files with whichever line-end convention makes sense.

CM+ has not yet fully addressed the MAC platform, although it did address both the NeXT computer (from which OS X comes) and MAC's AUX OS (MAC's first Unix).

Dashboards and Work Stations
Dashboard technology started out as a way to monitor project status from a high level.  The ability to zoom into details was quickly added. Next came the ability to use the dashboard to do work - at this point I like to refer to this type of dashboard as a "Work Station".   On the heels of this was the ability to customize the dashboard.  This started out as a development tool for the tool developers, but now the push is on to let the customer customize.  

A next generation ALM tool must let the customer customize dashboards.  The customer knows, for each role, what is needed.  And although CM and many ALM functions are well understood, they are far from any sort of standardization.  CM and ALM are among the most diverse functions, with a common goal, that I've seen.  And it will stay that way as new development methodologies continue to evolve.

Back to the main design goal of CM+... the way you want it.  So it was no different with dashboards.  CM+ already had in its architecture a GUI generation capability that allowed you to put data, notes pick-lists and other form-like data on a panel so that arbitrary prompt dialogs could be easily generated. Neuma extended this technology for its late 3G releases, and then more for its 4G releases.  It`s now easy to specify a custom dashboard through a single command, though this is usually broken up onto multiple lines.

So, to give an idea of what I mean by "easily" customized, consider a dashboard such as the Problem Dashboard defined by:

dashboard ?/products/[@cur product]Product
?,{@data 'revs rootnode ?Product' stream}[@cur stream]Stream
?,<Date>10x32[9/10/01]Since_Date
?/probs product ?Product status < fixed/(stream priority)#Problems_By_Stream
?,/probs product ?Product stream ?Stream/100(priority status)||Priority_By_Status  
?(probs)[status]Sort_By  
?,(probs)[priority]And_By
?,/probs product ?Product stream ?Stream status < answer/(:8 status priority assignee title:40)Open
?/probs product ?Product stream ?Stream sort ?And_By sort ?Sort_By/7(:8 status priority assignee title)##Problems
?,<>8x100[>get -term ?Open -field notes]Notes
?/probs product ?Product dates.orig > ?Since_Date/80(dates.orig:32)|Arrival
?,/probs product ?Product dates.fixed > ?Since_Date/80(dates.fixed:32)|Fixed
?'Problem Dashboard'

Each line above corresponds to one of the widgets on the dashboard.  Each prompt starts with a ? and ends with a name.  In some cases earlier names are referenced (?Name) to make the widget dependent on a previous one.  But overall, this specification is very straightforward, at least when you understand the basic widget specification.  I'm certain any techie out