[Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx>]

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?
> 
> 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.
> 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?
> 
> 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.
> 
> 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.

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
>