Re: [rainmap] RFC on UI mockups

[alexandru <alex () hackd net>]

On 2010-05-31, at 11:53 AM, David Fifield wrote:

> On Sat, May 29, 2010 at 05:59:57PM -0700, Fyodor wrote:
> > > Now included at the bottom of the scan is the full nmap command. The
> > > user will be allowed to click it and then copy it from a pop-up
> > > dialog. Since scans have names and the full command is readily
> > > visible, I've opted on removing the host/IP column. 
> >
> > Looks good (http://rainmap.labs.hackd.net/).
>
> On the topic of Nmap command lines, I want to make sure that you, Alex,
> are aware of the NmapOptions class in Zenmap,
> zenmap/zenmapCore/NmapOptions.py. It has a command line parser that
> produces an object whose attributes you can query. It was written for
> the profile editor in Zenmap, so that the user could enter a command
> line and have the GUI widgets automatically update themselves. It has
> the additional benefit that to store profiles we don't need to keep a
> bunch of flags like "OS detection?" "traceroute?" but can just store the
> text string.

Upon further review of both the Zenmap UI and the aforementioned class (Fyodor also brought it up during our last 
meeting) I think the most sensible approach would be to take an approach to UI similar to Zenmap's. I see a big benefit 
in allowing users that are familiar with Zenmap already to quickly transfer that knowledge over to Rainmap.

Are there any parts of the Zenmap profile editor UI that anyone has ideas for improvements for? I mean this both in 
terms of grouping of options (though that seems quite straightforward) and other usability concerns. David, I reckon 
you might have spent the most amount of time thinking about it, so maybe you have some ideas queued up already.

It's also likely that I will be storing the command string textually in the DB, parsing it with NmapOptions when 
needed, and enforcing user privileges server-side after it's been manipulated by a client. There would be scaling 
issues with my original design (the breaking of options into overly-simplistic categories) largely because it tried to 
be a bit too user-friendly.


Thanks for the feedback!

--
@

Attachment: PGP.sig
Description:

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/