Wireshark mailing list archives

Previous By Date Next
Previous By Thread Next

Re: Capture start and capture stop icons in the toolbar

From: Michael Tuexen <Michael.Tuexen () lurchi franken de>
Date: Sat, 22 Dec 2012 22:37:29 +0100
On Dec 22, 2012, at 8:31 PM, Evan Huus wrote:


So I finally got back to this and played with some of the
platform-specific features as well as some of the features that have
landed in trunk since 1.8 was released.

I have linked two more wireframes.

== Input v2 ==

The first wireframe [1] is a second draft of the "Input" tab for the
Capture Options dialogue. It is similar to my first draft, with the
following differences:

- Replaced "Add Pipe" with "Add..." since there are several different
interface types we might want to add, and put an equivalent "Delete"
button beside it.

- Minor string change for "Use promiscuous mode on all interfaces" checkbox

- Make it a little clearer that the "Help", "Start Capture" and
"Close" buttons are outside the tab frame. This applies to the other
two tabs of the dialogue as well, but is sufficiently trivial that I
didn't redraw them.

- Add the default capture filter field that is now in trunk. I
reworked this slightly by putting it into its own subframe and adding
some buttons. The button that was previously doubling as a label has
now been put on its own as "Manage Filters...". A "Save..." button was
added for creating new saved filters without opening up the Manage
Filters dialogue. "Compile" got a string change - the term "BPF" is
jargon that we shouldn't be exposing except in special circumstances
(I debated removing this button altogether, or perhaps renaming it to
"Show Compiled Form...", any thoughts?).

== Add Interface ==

The second wireframe [2] is a completely new dialogue that would be
opened when the user chooses "Add..." in the Capture Options dialogue.
It has a Name and Type fields, and a "Details" subframe that changes
depending on which type is chosen. The rest should be fairly
self-explanatory.

====

I also plan at some point to wireframe a new version of the "Edit
Interface Settings" dialogue that is launched currently by
double-clicking on an interface, but I'm not sure when I'll get around
to it. I hope to integrate the special Windows-only "Interface
Details" panel into it if I can.

Thoughts? Constructive criticism is always welcome :)

The table in the Input pane shows next to each other the friendly name,
and addresses (and a traffic curve). Does this fit? The friendly name can
be long, as the IPv6 addresses are. That is why we currently display
them not next to each other, but below.

It would be nice to have the columns to be configurable, such that I
can see the settings (which are important for me) without clicking on
the Options button.

Best regards
Michael


Cheers,
Evan

[1] https://dl.dropbox.com/u/171647/Wireshark-Wireframes/1.%20Input%20v2.jpg
[2] https://dl.dropbox.com/u/171647/Wireshark-Wireframes/4.%20Add%20Interface.jpg

On Sat, Dec 8, 2012 at 11:06 AM, Michael Tuexen
<Michael.Tuexen () lurchi franken de> wrote:

On Dec 8, 2012, at 4:17 PM, Evan Huus wrote:


On Sat, Dec 8, 2012 at 10:02 AM, Michael Tuexen
<Michael.Tuexen () lurchi franken de> wrote:

On Dec 8, 2012, at 3:15 PM, Evan Huus wrote:


On Sat, Dec 8, 2012 at 7:57 AM, Michael Tuexen
<Michael.Tuexen () lurchi franken de> wrote:

On Dec 8, 2012, at 3:49 AM, Evan Huus wrote:


I have drawn and scanned three mock-up sketches (linked at the
bottom), one for each of the three tabs I proposed in my previous
email. Apologies in advance for my inability to write legibly or draw
straight lines -- I am happy to "translate" for people who can't
decipher it :)

Again, these are just what's been kicking around in my head - I'm sure
there are lots of issues with them still. Constructive criticism is
very welcome.

One point brought up a couple of times was that increasing the number
of clicks to do a specific job is not good. And at least some uses
want to navigate with the keyboard. That is my main concern when
choosing multiple tabs. What do others think?


I agree that increasing the number of clicks isn't good if we can
avoid it, but neither is overwhelming the user with too many options
at once. The current dialog has (approximately) 7 major sections, one
of which is quite complex (the interface list). Different UI Design
guides quote different numbers here, but most of them agree you don't
want to present any more than 4-6 distinct sections at a time to
prevent overload.

I have to admit that neither me not Irene have particular GUI
knowledge. We just started what was there and tried to improve it,
without changing it too much...


I don't have any particular training either, I just read a lot of
random design stuff on the internet :)

Haven't even done that...




Keyboard navigation is quite possible with tabs (assuming they're
implemented correctly) and in this case may actually be faster. In the
current dialogue it takes me 16 keyboard presses to get to "Enable
transport name resolution" from the default top of the dialogue. In
the tabbed dialogue I calculate it would take me only 8, which is a
significant win.

Agreed.




A few additional notes on each sketch:

== 1. Input ==

This tab merges the "Capture" section of the current "Capture Options"
dialogue with the current "Capture Interfaces" dialogue. I have
removed several of the columns from the interface list, as most of
them were unnecessary for a summary view and made the dialogue far
wider than the actual default window size (horizontal scrolling is
bad). I replaced the "Packets" and "Packets per second" columns with a

The set of columns currently shown is configurable. I wasn't sure
which information is important and which not. I thought it might
depend on the use case. Personally, I never use the interfaces
dialog... But why do I need the traffic to select which interface
I'm going to capture. Most of the time I make the choice based
on the interface name or the IP address.


If it depends on the use case, then configurability is a good thing,
but the default should be fairly minimal.

I think the old version was showing a lot. That is why we started
with showing it and give the user the possibility to disable
columns.


How does one configure it? I can't click-and-drag, it has no
right-click context menu, and I don't see anything obvious in
Wireshark's global preferences...

Right click on the column title works for me. If that doesn't
work, it is a bug. Haven't tested Windows for a while...


This is actually on 1.8.2 on Ubuntu - it does work in trunk on the
same machine, so perhaps this is something that got added after 1.8
was released?

Correct. This is part of the improving of the current capture interface
dialog I was talking about. Since it doesn't address a real bug, Irene's
changes were not scheduled for backporting to trunk-1.8. I guess they
will be included in 1.10 once it will be released.




I included the sparklines because the current "Capture Interfaces"
dialogue includes a live packets/second count. I suspect it's useful
for new users who don't know their interfaces to be able to see that
"the one I want to capture on is the one all my traffic is coming on",
but I'm not particularly attached to it if there isn't actually a use
case for it.

Maybe... Our decisions were based on our needs and the feddback we
got on the mailing list. So maybe there is a need for real time graphing
in the capture options dialog, just no one complained about that...



single sparkline column, since we're using those other places in
qtshark and they give a good compact overview of the traffic level. I
also kept the explicit "Options" button column since it's more
discoverable than double-clicking.

That is correct. However, we didn't go for a button to save space.
We could reconsider this choice. What do others think?


One of the reasons I dropped some of the other columns was to make
space, since I figure the discoverability of the extra configuration
options was more important than displaying read-only copies of some of
those values. Consider the case where the user wants to enable/disable
promiscuous mode for a specific interface. Currently they can see the
value but can't edit it directly (which is potentially annoying), and
to edit it they have to double-click on the row (which isn't bad, but
is not as discoverable as the button). In the new design it wouldn't
be visible at all, but there's a nice friendly button for more options
which brings up a dialogue where they can both see and edit the value
they want.

The drawback is that I don't see the current configuration. I have
to double check each interface by clicking on the options button.


Yes


I normally check the capture filter and promiscuous mode settings,
sometime also the buffer size. That is why I found it nice to
see the summary currently presented.


Those columns should certainly be addable, but I'm not convinced
they're worth displaying by default (I've never really used any of
them, for example).

It would be worth getting more data on which columns people use though...

I guess this might be crucial point:

We did our design based on our requirements and asked for feedback on
the list before implementing and after committing the code. We got some
before the development, we got really some substantial feedback from
other developers. Irene implemented most of the suggested stuff and
improvements. So the solution we have right now is much better than
what we came up with. However, we didn't get much feedback from users
not being (core)-developers...




One of the other design principles I was working from is that one
should avoid displaying read-only copies of editable fields, as the
user will want to edit them and get annoyed when they can't.

I remember that we were thinking about it, but I'm not sure why
we didn't do it that way. Maybe Irene remembers...




I also completely got rid of the "Manage Interfaces" dialog by
spreading its functionality around a bit. Local interfaces can be
hidden/unhidden via a "Hide" (or "Unhide", depending) option in their
right-click context menu (not shown in the sketch). The "Show hidden
interfaces" checkbox allows users to unhide otherwise-hidden
interfaces temporarily.

Pipes can be added via the "Add Pipe..." button which directly opens a
file-chooser dialog. Pipes can be deleted via a "Delete" item in their
right-click context menu (not shown in the sketch).

The Add pipe button doesn't scale. Where do you manage remote interfaces
(if available)? We also envisioned the addition of other mechanisms like
using PSAMP/IPFIX kind of stuff, integrating ssh based stuff. Scalability
to multiple interface types was what we had in mind here.
So at least the remote interfaces need to be added back.


Fair enough, I wasn't aware of these. I still believe that management
of existing interfaces can (and should) be done through the primary
list via context menu items and their individual Options dialogues,

Hmm. But adding interfaces of another host is not within the context
of an existing one...

but perhaps "Add Pipe..." isn't the right choice. Would some sort of
"Add Interface..." button be more appropriate if it spawned an actual
minimal dialogue instead of a straight file-chooser?

It can bring up the tab style window. We thought it is a good idea
to have a tab for each kind of interface... Like local ones, remote
ones (rpcap), pipes, and possibly others in the future. We wanted
a generic term like manage, since (I think) we can't only add interface,
but also remove, rescan the local ones and so one.


Again, I think removing/editing should be done from the master list.
Perhaps 'rescan' should also be a button in the main window. Limiting
the additional dialogue to adding-only should allow us to greatly
simplify it, perhaps even using a drop-down list for the type of
interface instead of a tab for each.

The information you need for adding an interface is very different for
different types of interfaces. We set up a machine with remote capturing
support for playing with it. So for a named pipe it is just a name, for
remote capturing there a several options (hostname, protocol, username,
password, some other options I forgot). That is why we went with a
tab style window...


I will have to think on this.

You might want to play with the features. Wireshark has several "plattform
specific" features we were not aware of initially...

Best regards
Michael






There are also a few minor string changes:
- "Capture all in promiscuous mode" -> "Always use promiscuous mode".
- "Start" -> "Start Capture"

These can be added to the current solution. I think this makes sense.


== 2. Output ==

This tab replaces the "Capture File(s)" section of the current
"Capture Options" dialogue. The "Use pcap-ng format" checkbox becomes
a drop-down list for output format, allowing us to add other file
formats if we want, and making it clear what the current alternative
to pcap-ng is.

The implicit temp file used when the "File" field is blank becomes an
explicit check-box. I also added an option to create a new file every
N packets in order to be consistent with the "Stop capture after"
options.

Also made some more string changes, mostly for clarity and to avoid
technical terms like "Ring buffer".

== 3. Options ==

This tab replaces the other sections of the current "Capture Options"
dialogue (Display Options, Name Resolution, and Stop Capture...).

The only real change (besides more string changes) is that the "Stop
capture" option gets a master checkbox which controls the availability
of three condition checkboxes.

So the main question is: Do we want to split up the dialog into multiple
tabs? And if yes, for which version? I think we introduced the new rewritten
dialog in 1.8 and are now refining it. So the improved version will be in
1.10. So I guess the the tabbed one would be in 1.12. Or are you targeting
1.10? This would mean we should improve the current one anymore.


Honestly, I was targeting qtshark with this and not the gtk version at
all (thus the use of sparklines). Some of the easy string changes can
go into the gtk version for 1.10 obviously, but I don't think it makes
sense to implement the whole thing twice.

OK. I haven't looked at the qt stuff at all. We had to touch the capture
options window to add support for capturing from multiple interfaces. Since
we wanted it in the current version, we worked on the gtk stuff (not sure
if at the time we started, the qt stuff was already there).
I also don't want to re-spend the effort completely. But whatever we
can improve, we most likely will. So any suggestion is welcome.


I am curious to hear what others think about the tabs though. Anyone
else care to weigh in?

Yes, anyone?

Best regards
Michael


Evan



Best regards
Michael


Cheers,
Evan

[1] https://dl.dropbox.com/u/171647/Wireshark-Wireframes/1.%20Input.jpg
[2] https://dl.dropbox.com/u/171647/Wireshark-Wireframes/2.%20Output.jpg
[3] https://dl.dropbox.com/u/171647/Wireshark-Wireframes/3.%20Options.jpg

On Fri, Dec 7, 2012 at 9:15 PM, Evan Huus <eapache () gmail com> wrote:

On Fri, Dec 7, 2012 at 3:46 PM, Michael Tuexen
<Michael.Tuexen () lurchi franken de> wrote:

On Dec 7, 2012, at 9:06 PM, Evan Huus wrote:


On Fri, Dec 7, 2012 at 2:41 PM, Michael Tuexen
<Michael.Tuexen () lurchi franken de> wrote:

On Dec 7, 2012, at 8:01 PM, Evan Huus wrote:


On Fri, Dec 7, 2012 at 1:47 PM, Gerald Combs <gerald () wireshark org> wrote:

For the Qt toolbar I created start and stop capture icons based on the
media player/recorder "record" (circle) and "stop" (square)
conventions[1][2]. "Record" makes more sense to me; we are recording
packets to disk after all. It also makes things easier if we ever get
around to adding a playback feature. My versions are
capture_start_24.png, capture_start_active_24.png, and
capture_stop_24.png in the "image" directory.


+1


A media-player-ized "capture options" icon could be a record button with
a superimposed wrench. I'm not sure about the "interface list" or
"restart capture" buttons however.


+1 for the "capture options" icon.

I would suggest that (in qtshark) the entire "interface list" dialog
be merged into the "capture options" dialog - there's a large amount
of information duplicated between them and they do almost the same
thing already. The dialog should generally be rethought at the same
time, as the current "capture options" dialog is already quite busy --
perhaps splitting it into tabs is the way to go? With the dialogues

Hi Evan,

the capture options dialog was rethought for 1.8 to support the
capturing from multiple interfaces. We wanted to clean things up
on the one hand side, don't change too much on the other.


That was already in trunk when I first started hacking on Wireshark :)

.. OK.


I'm not too familiar with the old (1.6?) dialog, but after a quick
glance at some old documentation screenshots it looks like the 1.8
version is already a lot cleaner than it was.


So if you have concrete suggestions how to improve the capture
options dialog box, Irene and myself will be more than happy
to discuss it. Please provide some feedback.


I have a bunch of ideas floating around in my head - I will try and do
some simple wireframes tonight, but for now, a quick summary:

Three tabs: Input, Output, Options
- Input tab contains some melding of the list of interfaces in
"capture options" and the list of interfaces in "capture interfaces".
- Output tab contains everything from the "Capture File(s)" section in
"capture options", plus possibly a few more we don't expose right now.
- Options tab contains the other three sections from "capture options"
(display options, name resolution, stop capture...)

I would like to get input also from others...

Our users are somewhat used to the current layout. So we should have
good reasons to change it. One reason would be to have space for
more options. Not sure.


My primary reason for re-organizing it this way is that the interface
list is already quite large (I have six interfaces listed) and if we
merge in the other dialog it will just get larger - the window will
end up too big with too many controls in it at once.

Open to other suggestions of course, but that's the problem I was
trying to solve.



Some misc other things I've been thinking about:
- it would be nice if the "Capture on all interfaces" checkbox lived
in the column title as a master checkbox (see the "In Store" column at
[1] for an example).

I think we follow (to some extend) the Human Interface Guidelines
for GTK. Do they have something like this?


Not that I've been able to find, though they do seem to have
multiple-selection checkboxes in some circumstances (see figure 6-12
in [1]).

[1] http://developer.gnome.org/hig-book/3.5/controls-check-boxes.html.en


- it would be nice if the "Prom. Mode" column contained editable
checkboxes, and the "Capture all in promiscuous mode" was a column
master checkbox as well

Same question as above.

- it's not immediately clear in the "Stop Capture..." section whether
multiple checked options will be combined with a logical AND or a
logical OR

Not sure, we took it over.


I suspect it's using OR, but I'm not sure where to look to find out.


- same AND vs OR issue with the various "Use multiple files" options

Not sure, we took it over.

- the "capture interfaces" dialog has a button for each interface,
whereas the "capture options" dialog has double-clickable rows -- I'm
not sure which one is better, but we should pick one (I'm leaning
towards the buttons)

You must be using Windows... Only on Windows you have a Details button
in the capture interfaces dialog. This is different form what you
get when double clicking on the capture options dialog box.
In the capture options dialog box we didn't use a button to save space...


I see that the "Details" button doesn't exist on my linux version - do
we not have access to that extra information on non-windows platforms?

I will send some simple sketches shortly.

Evan


Best regards
Michael


I'm be very happy to discuss further, this is all just
back-of-a-napkin ideas right now.

Cheers,
Evan

[1] http://dhtmlx.com/docs/products/dhtmlxGrid/samples/08_filtering/03_pro_filter_num.html


Best regards
Michael

merged we only need one icon, which can be the record button with a
superimposed wrench.

For "restart capture" I would think we should be using a record button
with superimposed "refresh" circular arrow people know from web
browsing. Perhaps the current "reload capture file" icon would be
sufficient there?


At some point I was hoping to see if we could get Elliott Aldrich (who
made the current document icon and several interface icons) to create
updated versions of the main toolbar icons including the capture ones.


[1] http://commons.wikimedia.org/wiki/Tango_icons#Media
[2] http://commons.wikimedia.org/wiki/GNOME_Desktop_icons#Media

On 12/7/12 6:38 AM, Maynard, Chris wrote:

+1

There was mention of these icons some time ago, but no changes were ever made: 
http://www.wireshark.org/lists/wireshark-dev/201107/msg00092.html

- Chris

________________________________________
From: wireshark-dev-bounces () wireshark org [wireshark-dev-bounces () wireshark org] On Behalf Of Guy 
Harris [guy () alum mit edu]
Sent: Friday, December 07, 2012 4:08 AM
To: wireshark-dev () wireshark org
Subject: [Wireshark-dev] Capture start and capture stop icons in the toolbar

On Dec 6, 2012, at 5:46 PM, gerald () wireshark org wrote:


Use a different "close" button in the main toolbar. It looks better but
is still wrong (on OS X at least).


As long as we're playing with the toolbar:

I've always found the icon on the "start a capture" button a bit non-obvious.  I guess it's supposed to 
be an image of a plug-in network adapter card for some parallel bus (although that's not the first thing 
that comes to mind when I look at it), but:

  1) the sorts of machines on which a lot of people run Wireshark have built-in network adapters

and

  2) even a lot of the add-on adapters out there plug into serial buses (USB, PCI Express/Thunderbolt)

so a "conventional PCI" card might be an out-of-date icon these days, and, in addition, a number of the 
other sniffers I've seen use the CD player "start" (right-pointing triangle, pick your color), "stop" 
(square, probably red or black), and, in some cases, "pause" (two parallel vertical lines) icons for the 
capture buttons.

("Pause" means "don't receive packets, but, if you click the pause button again, continue capturing with 
the same options, without discarding or saving the already-captured packets.")



___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
       mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
       mailto:wireshark-dev-request () wireshark org?subject=unsubscribe



___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
        mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
        mailto:wireshark-dev-request () wireshark org?subject=unsubscribe



___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
         mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
         mailto:wireshark-dev-request () wireshark org?subject=unsubscribe



___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
          mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
          mailto:wireshark-dev-request () wireshark org?subject=unsubscribe



___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
           mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
           mailto:wireshark-dev-request () wireshark org?subject=unsubscribe



___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request () wireshark org?subject=unsubscribe



___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Previous By Date Next
Previous By Thread Next

Current thread: