Re: [rainmap] RFC on UI mockups

[alexandru <alex () hackd net>]

On 2010-06-01, at 11:17 PM, Fyodor wrote:

> On Mon, May 31, 2010 at 03:47:42PM -0700, alexandru wrote:
> > 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.
>
> Good ideas.  I agree that Zenmap's powerful NmapOptions class is the
> sort of approach we should take, and maybe we can even reuse some of
> the same code, and some of the same option grouping.  But Rainmap
> isn't meant as a full featured Nmap GUI like Zenmap is, so it doesn't
> need to offer nearly as many options.  This makes it easier for us to
> implement and secure, and easier for users to use.  For this reason,
> we can probably fit the scan options on one page rather than dividing
> them into 7 tabs as Zenmap does.  Of course the options should still
> be grouped together by purpose even on the same page.

Upon further discussion during our weekly meeting today, Fyodor and I prioritized which of Nmap's options will be 
offered in Rainmap v1.0:

        http://rainmap.labs.hackd.net/features/

If you have strong opinions about why something should be prioritized differently, please chime in.


It should be much easier to construct the interface for the "new scan" view, now that there is a clear picture of 
exactly which options will be offered.


I think Rainmap should, eventually, offer the same options as Zenmap, to satisfy users who may want to self-host it. 
But as with any software, we'll build it piece by piece. After all, there's gotta be some work left-over for v2.0 ;) 
That said, the interface should be extensible enough so that it can present *all* options if so configured, without 
requiring a (complete) redesign.

> For example, Rainmap won't have to do Idle scans, FTP bounce attacks,
> -iR, user-specified -iL, or anything at all from the "Source" tab.
> Most of the "timing" tab is unneccessary as well.
>
> Cheers,
> Fyodor
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/


--
@

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/