Re: [rainmap] RFC on UI mockups

[alexandru <alex () hackd net>]

On 2010-05-31, at 6:49 PM, David Fifield wrote:

> On Mon, May 31, 2010 at 03:47:42PM -0700, alexandru wrote:
> > 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.
>
> I don't have any recommendations now, more like anti-recommendations.
> The Zenmap profile editor is constructed dynamically from
> share/zenmap/misc/profile_editor.xml. That's something I've thought
> about getting rid of, so I suggest not using that as the basis for the
> web GUI. It's nice because you can add an option just by editing the XML
> file, but it's also inflexible and I think it hurts the flexibility of
> the interface. We're going to have to work around it to add
> Kirubakaran's script selection interface, for example.

I'm planning on just coding the web interface piece by piece. I don't foresee any significant challenges, since even in 
terms of adapting it for new features it'll just mean someone has to modify a few things in the template that serves 
the page (and plug in a newer parser)

Out of curiosity, beyond having to also modify zenmapGUI/OptionBuilder.py when a new entry is added to the XML, what 
other issues did you find with the profile_editor.xml approach? I ask because having a helper file to store the various 
help descriptions and option values is something that crossed my mind. I've skimmed the code, so I may have skipped 
over something obvious — apologies if that's the case.

> There used to be a "command wizard" in Zenmap that offered the same
> options as the profile editor, but forced you to go through the tabs in
> order using next/previous buttons. We removed that because it's better
> to have all the options at your disposal from the beginning. This is
> especially true when you've got a nice tall web page to deal with.
>
> I can imagine that you want to highlight the most common options
> somehow, so you don't have to hunt for them in an exhaustive list of
> options. Maybe a separate section at the top with the most-used options,
> and then sections for "Timing," "Source," etc. below that. The named
> sections should repeat options that are also in the most-used category,
> so you can find them in either place.

My plan is to replicate the existing interface almost 100%, including the tabs (and the help system), since I don't 
think that a long-scrolling webpage is going to work as well. This is likely the only part of the app where having 
JavaScript enabled would significantly improve the experience. For people choosing not to browse with JS, the fallback 
will likely resemble the very long page with many options that you describe. 

Thanks!

> David Fifield
> _______________________________________________
> 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/