[Owasp-o2-platform] Feedback

Arshan Dabirsiaghi arshan.dabirsiaghi at gmail.com
Thu Nov 19 01:02:29 EST 2009


+100000

Never used O2 since I installed it. Either needs a massive UI rebuild  
or 100 webcasts to explain your everyday use cases.

Sent from my iPhone

On Nov 18, 2009, at 11:08 PM, Rohit Sethi <rklists at gmail.com> wrote:

> Dinis et al, this project is very promising. Although I've known about
> O2 for a while now, today was the first time I actually installed the
> tool. Dinis, when you demonstrate the capabilities of O2 it's
> awe-inspiring, but I imagine many people feel the same way as I do
> when they actually install the tool: overwhelmed. I suggest you apply
> the principle of "information hiding" to the design of the application
> - provide people with a basic, simple view of the application and give
> them the option to expand on more advanced features when needed. I
> have some ideas for you, but I'm ashamed to say I don't have the
> bandwidth to actually implement them :(
>
> A few specific suggestions:
> •    Is there a public bug tracking system? If not this is an invalu 
> able
> tool to solicit feedback and track bugs on an ongoing basis. You
> should provide a link to the bug-tracker from the main OWASP O2 page
>
> •    What was the rationale for creating a new GUI? In particular, w 
> hy
> didn’t you just piggyback off an existing, pluggable IDE like Eclips 
> e?
> I'd guess the answer is because O2 is developed (I’m assuming) in .N 
> et
> and probably through Visual Studio in order to facilitate GUI widget
> development. You’ve created a new look and feel which then requires
> the end user to understand the new look and feel in order to make
> sense of the application. Although I can appreciate the choice to go
> use .Net instead of Java, I wonder if copying some of the GUI
> conventions of Eclipse might be useful (more on this later). Note that
> I’m no usability expert, but I’d like to share my thoughts anyway. 
>  I
> would seriously suggest freezing new feature development for a while
> and focus on improving usability; once the application is easier to
> use, hopefully the user base will grow and so will the pool of
> developers willing to pitch in. In general try to minimize the amount
> of information in each dialogue box, and provide expandable, grouped
> advanced options.
>
> •    I think O2 would be better served as one application with vario 
> us
> 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 */
>
> •    Do you really need the modules that allow people to run the sca 
> nner
> from within O2? I argue this causes too much confusion for it’s actu 
> al
> value
> •    If you use the above-suggested layout, Web Inspect Converter a 
> nd
> other Blackbox scanner import tools should be Wizards to import data
> into a project’s Scanner Results rather than new modules
>
> Cheers,
>
> -- 
> Rohit Sethi
> Security Compass
> http://www.securitycompass.com
> _______________________________________________
> Owasp-o2-platform mailing list
> Owasp-o2-platform at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-o2-platform


More information about the Owasp-o2-platform mailing list