[Michael Mann <mmann78@xxxxxxxxxxxx>]

One of the reasons I try to stay away from UI design/development is that I'm never sure if new ideas for existing behavior are "good", "bad" or they are "good" but existing users react with "who moved my cheese?"

Some dissectors having a preference for their TCP/UDP port and forcing others to use Decode As is the inconsistent UI behavior that I would like to change.  To me that is different than "different paths" in the UI (For example having Decode As dialog (for TCP-> XXX) as currently constructed and all TCP dissectors having a section in their preferences for "reverse Decode As" (apply this to TCP port).

 

I just wanted to mention the "big picture" as something to move towards.  Adding "other parts" to the UI (as long as they are consistent for ALL dissectors) is fine with me.

 

 

 

-----Original Message-----
From: Guy Harris <guy@xxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Fri, Feb 5, 2016 4:18 pm
Subject: Re: [Wireshark-dev] Do we really need port preferences for dissectors?

On Feb 5, 2016, at 1:00 PM, Michael Mann <mmann78@xxxxxxxxxxxx> wrote:

> I'm not surprised we're getting those questions, but for me I'd like to work towards the goal of providing an overall solution for heuristics and get away from dissector specific ones.

There's "dissector-specific" in the code and there's "protocol-specific" in the UI. The two are not rigidly tied together.

I *really* don't want to have users who just want to tweak the way Ethernet MPLS pseudo-wire dissectors have to pop up "Enabled Protocols" , search for "PW" or "Ethernet" in that huge list, and enable or disable the appropriate protocol - or possibly pop up Decode As and have to *create a new entry* - rather than popping up a dialog that presents an *existing* list that *includes* MPLS, and lets them select the MPLS item and edit it.

I.e., I think 2.x's UI for changing those settings is inferior to 1.x's, even if the underlying *dissector code* is cleaner. I think the set of questions we're getting is a sign that, at the UI level, we've made a mistake and reduced the usability of Wireshark.

> Right now the functionality I'm talking about fits into our existing Decode As, so that's why I'm suggesting putting it there.

I think we should rethink how the Decode As UI works *now* before adding anything to it.

For example, we should have at least one dialog that includes entries for every protocol for which you *can* adjust settings, *regardless* of whether the user has changed any settings from the default.

> Long term (probably post 2.2 release) I'd like to see Decode As, enable/disable protocols, enable/disable heuristic dissectors, "conversation Decode As" (and maybe other items I'm forgetting) all somehow merged into a single UI data representation.

Single *internal* data representation, fine.

Single *place in the UI*, not necessarily. From the UI standpoint, what matters is how obvious is it to the user where to do something, *not* how clean the data structures are - we may well have different parts in the UI for different types of things in the data structure.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe