[Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx>]

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

> On Sat, Dec 8, 2012 at 7:57 AM, Michael Tuexen
> <Michael.Tuexen@xxxxxxxxxxxxxxxxx> 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...
> 
> 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...
> 
> 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.

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.
> 
> 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.
> 
>>> 
>>> 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@xxxxxxxxx> wrote:
>>>> On Fri, Dec 7, 2012 at 3:46 PM, Michael Tuexen
>>>> <Michael.Tuexen@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> wrote:
>>>>>>> On Dec 7, 2012, at 8:01 PM, Evan Huus wrote:
>>>>>>> 
>>>>>>>> On Fri, Dec 7, 2012 at 1:47 PM, Gerald Combs <gerald@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx [wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris [guy@xxxxxxxxxxxx]
>>>>>>>>>> Sent: Friday, December 07, 2012 4:08 AM
>>>>>>>>>> To: wireshark-dev@xxxxxxxxxxxxx
>>>>>>>>>> Subject: [Wireshark-dev] Capture start and capture stop icons in the toolbar
>>>>>>>>>> 
>>>>>>>>>> On Dec 6, 2012, at 5:46 PM, gerald@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx>
>>>>>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>>>>>          mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>>>>> ___________________________________________________________________________
>>>>>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>>>>          mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>>>>> 
>>>>>>> 
>>>>>>> ___________________________________________________________________________
>>>>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>>>           mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>>> ___________________________________________________________________________
>>>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>>           mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>>> 
>>>>> 
>>>>> ___________________________________________________________________________
>>>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>>>            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>> ___________________________________________________________________________
>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>>            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>> 
>> 
>> ___________________________________________________________________________
>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>