Re: [rainmap] RFC on UI mockups

[alexandru <alex () hackd net>]

Thanks for the feedback, everyone! My thoughts and updates below (and check http://rainmap.labs.hackd.net for new 
mockups)

On 2010-05-25, at 3:59 PM, Fyodor wrote:

> On Mon, May 24, 2010 at 09:26:48PM -0700, alexandru wrote:
> > Hello all,
> >
> > I've created a few UI mockups for the hosted scanner to show the
> > 'first contact' interaction process. The mockups and a scenario
> > walkthrough are at http://rainmap.labs.hackd.net/ and I'm looking
> > forward to your comments/ideas.
> >
> > I'll follow along in the coming days with more details on what
> > happens once the user has logged in (review scan results; create more
> > scans etc)
>
> Thanks, Alexandru.  These look great, and really help us bring more
> concreteness to this project.  I didn't have a lot of time to review
> this today, but here are some comments on the individual mockup pages:
>
> =Screen 1 - Home Page=
>
> I think this page should be dominated with a description of the
> service and what it has to offer rather than a login/sign-in form
> taking up most of the page.  Of course there will still be prominant
> links to the sign-up form page, and probably log-in fields embedded in
> the page smoewhere.
>
> I think the "self-host" button can be changed to "about".  Actually,
> you might be able to move those buttons to the left side like on the
> logged-in screen, except of course some of the logged-in buttons won't
> be relevant at this (not logged in) point and can be omitted or
> disabled.

Done. I agree the top links should've gone on the left side from the get-go: this way users always know where the 
controls are and we provide some visual consistency throughout the application.

As for Luis' question re: disabling sign-ups, that will be an option, as will be review-before-activate (similar to 
what the folks at http://devio.us do)

> =Screen 2 - Sign-up=
>
> The sign up form will probably ahve a few more fields.  At a minimum
> we will want a name.  At some point I think we'll want an account type
> selector there too.  Some account types may require approval by an
> admin.  For right now it is probably OK to make them all guest
> accounts, and we'll provide a way for admins to upgrade accounts with
> greater capabilities (e.g. to scan more hosts).

I've included a tentative 'account type' dropdown in the mockup so that we know how account selection will look like on 
the page.

As for the name, would it perhaps be less annoying to ask users to update their profile *after* they activate the 
account, instead of requiring more info on sign-up? I think there's less friction that way.

> =Screen 4 - Dashboard=
>
> I guess "Name" is an identifier assigned to a scan when the user
> creates it, and the scan can be rerun/scheduled as desired?  I guess a
> "name" describes a specific set of Nmap options and targets?

Yes, and I made that more evident in the "new scan" view. I figure users will have an easier time remembering a scan by 
an identifier they can choose, and it's also better than showing hostnames or IPs as in my initial design.

> The "host" and "IP" columns might be confusing when people scan many
> targets at once.  For example, a user could list 50 hostnames, or give
> specifiers like scanme.nmap.org/26.
>
> I'm not sure about the best way to show this information in the UI,
> but here is some information which may or may not be worth putting in
> the recent scans table:
>
>   o Scan start/end time and date (maybe just the start time/date)
>
>   o Nmap options specified for scan, and targets specified for scan.
>     Maybe you could get these by hovering over or clicking on the
>     scan name or small icons.  Like if you clicked on the scan name,
>     maybe a modal dhtml box could appear which shows the full command
>     line and targets.

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. 

>   o You might want to show the most recent scans even if some of them
>     have already been viewed/emailed/downloaded (the sticky note
>     makes it sound like those would disappear from the dashboard).
>     Perhaps there could be a way to identify whether scan results
>     have been viewed before (maybe the HTML "followed links" tracking
>     would be enough).  Perhaps the layout could be reused for the
>     "results" list page (or maybe you won't even need that page).

I'll use something similar to the "followed links", but instead colour the entire background for the items that haven't 
been viewed (etc) yet.

> The "faq" sidebar link should probably be "help" as it could link to
> various documentation options, including the faq and the tutorial you
> mentioned on screen #3.
>
> The "skip" link in the Schedule "actions" should probably be labelled
> "cancel" as that is more usual.  Maybe it would give you the choice to
> cancel just that one scan, or all of the scans scheduled with the
> given name.
>
> If there are more than 5 scheduled scans, you might provide a
> scrollbar like in the "recent scans" table.
>
> Regarding these three buttons:
>  scans - completed scans; lets users create new ones
>  results - see scan results; email, download, run diffs
>  schedule - edit upcoming scans; modify the schedule
>
> I'm not sure that the "scans" button needs to include "completed
> scans", as the "results" button will presumably give such a list.  I'd
> suggest changing "scans" to "New Scan" and use it just for creating
> and scheduling a new (possibly recurring) scan.

I've gone further and removed the 'results' and 'schedule' panels. So right now "scans" gives a list of all the scans 
the user has created, and they can edit, schedule etc as appropriate. Since completed scans are shown on the dashboard 
anyway, it would be redundant to show the same information under two tabs.

It's possible that once I test with more data I'll feel like a separate tab may allow for easier searching of results 
etc. and bring that design back.

> We should probably capitalize the labels on the left-sidebar buttons
>
> For the one we host, we'll probably want a way to embed it in the
> normal Insecure.Org chrome (like you see around the content of
> nmap.org, insecure.org, sectools.org, seclists.org, etc.)

It should only be a matter of slapping on the appropriate CSS to turn the left-side navigation into links as on 
nmap.org etc. Or am I misunderstanding the kind of embedding you have in mind?

> =General Notes=
>
> It will be great to see the new scan screens and admin screens :).

The "new scan" and "inbox" (messaging centre) screens are up. Admin will come tomorrow.

"New scan" may change; this screen is one of the more challenging ones, because while it's easy enough to show a list 
of checkboxes to the user, it wouldn't be the optimal choice or the most intuitive to use. I'm constantly going over 
alternate designs and may update this — I'll let everyone know.

In case it's not obvious from the mockups, for "extra options" those buttons are either pressed or depressed, depending 
if the user selected the option or not; the idea here is to avoid checkboxes/radio buttons for some of the 
binary-choice options and save space. I also think the form looks less daunting this way.

> For a first mockup, these are looking good!
>
> 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/