O2 GUI - Create Rohit's GUI PoC

[GoogleCodeExporter]

Title?
Rohit made a great post to the O2 Mailing list in which he described how he 
thinks an O2 GUI 
should look like so that it makes sense to new users.

The objective of this task is to create an PoC which shows an O2 Module 
containing the look and 
feel Rohit is describing below

Execution details:
For the PoC Stage this should be done via an XRule

Description?
•       I think O2 would be better served as one application with various
features and extensions, rather than a loosely coupled collection of
modules. Not only will this help lower the learning curve to the
application, it will help clarify the user interface. Going back to
the Eclipse point, why not start with the concept of a “Project”? Each
project relates to an individual application, and is comprised of
several child elements. You can even have a Project Explorer /
Navigation similar to what Eclipse has. Rather than dragging and
dropping source files into different module windows, there should be
one location of source files within the projects and the modules can
reference those source files.
Here’s an example of a potential Project structure:
Project
  -Input
      -Scanner Results (e.g. .ozmat)
      -Source Files (e.g. .class, .xml)
  -Analysis
      -Findings (e.g. Ounce findings)
      -Rules (e.g. Ounce rules)
      -Scripts (e.g. Python, Java, C# scripts, etc.)
      -Intermediate Representation (e.g. CIR objects)

•       I appreciate the flexibility in offering discrete modules of O2
functionality; however, in its current format, I had a hard time
distinguishing between which functions are "Core O2 functions" and
what were really extensions. I suggest that you create a single GUI
which users can identify as the "O2 application". Similar to IDEs like
Eclipse, users could open the GUI and then select different views or
perspectives based on the features they wish to use. Similarly, I
suggest creating a single Windows installer that installs all Core O2
functions along with the single GUI (e.g. Rules Manager, Join Traces,
O2 Scripts, Findings Query, Findings Viewer, Findings Filter, Search
Assessment Run, etc.). Provide an option for custom installation in
case people want to scale down the features. Provide an interface to
install "extensions" such as Spring MVC or support for CSharpScripts,
etc.
Here’s what I’d recommend for the top level menus of the Core O2 
application:

File
  -New /** starts a new project, perhaps with a wizard to help guide
the user */
  -Open
  -Save
  --------
  -Import /** import findings from various scanners */
  ---------
  -Exit
/** Get rid of restart modules - this might be a useful debugging
concept but doesn't make sense to end users. Somebody should open and
close the app if they need to do this */

Edit
 -Cut
 -Copy
 -Paste
 -------
 -Configuration /** opens a dialog window with top level choices on
the left and details on the right, similar to Eclipse Preferences */
     -File System /** Top level choice */
        -File Location
        -Install Directory
        -Temp Directory
        -Executable Directory
     -Module Specific /** One top level choice for each module that
requires configuraiton */
     -Advanced /** Top level choice */
        -(other configuration items from the KO2Config)
/** Provide a radio button on the top to allow users to toggle between
Main configuration and user-specific configuration */
/** Provide standard Save and Cancel buttons on the bottom of the
dialogue window */

Modules /** Each should bring up a different dialog box */
  -Search
  -Rules Manager /** don't distinguish between XRules and other kinds
of rules - this is confusing */
  -Log Viewer
  -Trace Joiner
  -Code Reflector
  -Script Editor /** should support  C-Sharp, Python and Java */
  -Findings Manager /** includes Filter and Viewer */
  -Intermediate Representation Viewer  /** or IR Viewer for short,
rather than CIR since this is now platform agnostic */
  -Technology-Specific Modules
      -Spring MVC
      -.Net /**Should include the .Net debugger (the web server
should be part of this functionality rather than a separate module),
.Net Callbacks Maker */

Windows /** no idea what functionality is supposed to be here */

Help
 -Online Knowledgebase (or Wiki) /** Link to owasp site */
 -Request Help from O2 Developers
 -About /** include version, developers names and the email address
to provide feedback, don’t need the Send Comment feature */

Original issue reported on code.google.com by dinis.cr...@gmail.com on 25 Nov 2009 at 10:57

[GoogleCodeExporter]

Rohit comment: "...I really believe that with the right amount of
information hiding we can greatly enhance the experience for new users.."

Dinis reply: I agree and what we need now is to figure out how this could look 
in practice. for example should 
we have a bunch of 'themes' or views in the main O2 module that can be 
configured using a specific ASCX 
control (maybe with a number of check boxes) so that the user can chose which 
features or capabilities he 
wants to be enabled.

From a technology point of view, maybe one way to do this is to add a number of 
annotations to O2 controls 
about that control, and then let the GUI decide what to show and what to hide 
(based on the content of those 
annotations)

Original comment by dinis.cr...@gmail.com on 25 Nov 2009 at 11:50

[GoogleCodeExporter]

I probably can't help with actual implementation as my Visual Studio experience 
is
limited. I can, however, talk about what each module should look like.

Have you given some thought as to what modules should be considered "Core"? My
thoughts are that CIRReview, Rules, XRules, JoinTracer, and Search Assessment 
Run
look like they might be good candidates.

If you were to prioritize one, which one would you select?

Original comment by rkli...@gmail.com on 26 Nov 2009 at 12:01

[GoogleCodeExporter]

Original comment by dinis.cr...@gmail.com on 4 Dec 2009 at 12:05