Ethereal Usability Enhancements

["Ulf Lamping" <ulf.lamping@xxxxxx>]

Hi List!

After having a deep thought about the usability of the Ethereal menu in general, and reading the "Human Interface Guidelines" both of Gnome and KDE, I would like to suggest a cleaned up menu structure and other minor usability enhancements.

As a new release will be come in the next days, I don't want to start changing things in CVS, before this release is out. Otherwise the users will be contronted two times with "major" GUI updates.

Please find attached a html document, which will outline the changes I'm thinking of. 

Feel free to send comments to this on the developer list (if you find an error, have an answer to one of the open question, ...)

Regards, ULFL
______________________________________________________________________________
Bestes Testergebnis: Stiftung Warentest Doppelsieg fur WEB.DE FreeMail
und WEB.DE Club. Nur fuer unsere Nutzer! http://f.web.de/?mc=021182

Ethereal Usability Enhancements

This is a document collecting some things where Ethereal lacks
usability. I know, that most of the topics are grown for a long time
now, and no one found the time to fix it.

This proposal is maybe not the ultimate solution, but I hope a step in
the right
direction, which will need a moderate effort to be implemented. All the
topics in this document are not "carved out of stone", feel free to
send me comments about the things described here. But please don't
suggest new features, as we should fix these usability things first,
before adding new features (as I can also imagine a lot of new features
too, not mentioned here).

Author: Ulf Lamping@xxxxxx
Date: 2003.10.21

1. Ethereal Usability Enhancements
   1. Main Menu
      1. Menu in Current CVS
      2. Usability enhanced
   2. Packet vs. Frame
   3. "Decode As" / "User Specified Decode" dialogs
   4. "Print" dialog
   5. Capture vs. Display Filters
   6. Save data/settings at Program Quit
      1. Capture file
      2. Preferences file

---

Main Menu

I have tried to improve the menu structure, to be more like common
applications and a bit more consistent to the user.

After comparing the current Ethereal menu implementation with the way
it could be, and have a deep look into the "human interface guidelines"
of Gnome and KDE, I would suggest the following new menu structure.

Menu in Current CVS

Just for reference, this is the menu as it currently is checked in CVS.

File	Edit	Capture	Display	Tools	Help
Open...	Find Frame...	Start...	Options...	Plugins...	Help
Close	Find Next		Match >	Follow TCP Stream	About Ethereal...
Save	Fine Previous		Prepare >	Decode As...
Save As...	Go To Frame...		Colorize Display...	Go To Corresponding Frame
Reload	----------------------		Colapse All	TCP Stream Analysis >
----------------------	Time Reference >		Expand All	Summary
Print...	Mark Frame		Show Packet In New Window	Protocol Hierarchy Statistics
----------------------	Mark All Frames		User Specified Decodes...	Statistics >
Print Packet	Unmark All Frames
----------------------	----------------------
Quit	Preferences...
	Capture Filters...
	Display Filters...
	Protocols...

Usability enhanced

This is my suggestion, how the menu could look like, to be a lot more
common to a normal user.

To get an idea, where to put each menu item in future:

• File: Input- / Output ...
• Edit: Search&Mark Frames / Edit Preferences
• View: Manipulate the behaviour of the output window
  
• Capture: Live capture of network data (includes filtering)
  
• Analyse: Captured data analysis (coloring, filtering, ...)
  
• Statistics: Various statistics of the captured data
• Tools: Internal and external tools
• Help: Give the user a helping hand
  

File	Edit	View	Capture	Analyse	Statistics	Tools	Help
Open...	Find Frame...	Show >	Start...	Coloring Rules...	Summary	Plugins	Contents...
Open Recent >	Find Next...	Timebase >	Stop (not Win32)	Display Filters...	Protocol Hierarchy		About Ethereal...
Close	Find Previous...	Name Resolution >	Capture Filters...	Match >	Conversation List >
--------------------	--------------------	Options		Prepare >	Service Response Time >
Save	Go To Frame...	--------------------		--------------------	Watch Protocol >
Save As...	Go To Corresponding Frame	Collapse All		Decode As...	IO >
--------------------	--------------------	Expand All		User Specified Decodes...	ONC-RPC >
Page Setup	Time Reference >	--------------------		Enabled Protocols...	RTP-Analysis >
Print Preview...	--------------------	Show Frame In New Window		--------------------
Print...	Mark Frame	Refresh		Follow TCP Stream
Print Packet	Mark All Frames			TCP Stream Analysis >
--------------------	Unmark All Frames
Quit	--------------------
	Preferences

Hints:

• The Italics items have to be newly implemented, the Strikethrough items have to be removed, compared to the current implementation.
• View/Refresh was former File/Reload
  

The three submenus below "View" will have the following items:

Show (checkitems)	Timebase (radiobuttons)	Name Resolution (checkitems)
Main Toolbar	Time of day	Enable MAC
Filter Toolbar	Date and time of day	Enable Network
Status Bar	Seconds since beginning of capture	Enable Transport
Packet List	Seconds since previous capture
Tree View
Byte View

Things left to think about:

1. HIG suggests "File/Close" item it just above Quit item.
   
2. Should the new toplevel item be called "Analyze" or "Analyse" or like something else?
   
3. Menu Item "File/Reload" - "File/Revert" - "View/Refresh"? Which name to choose and where to put? We don't Revert to Saved, as we don't change the file after it is once created, so maybe "View/Refresh" is the best choice.
   
4. Is it better to remove Capture toplevel completely (and move items somewhere else, but where)?
5. What does the "Go To Corresponding Frame" item do? And where to put it into?
   
6. What is the right sequence of the "Statistics" items? Should be going from general to more specific things.
7. Put "Tools/Plugins" into "Help/About Plugins" and remove "Tools" completely? Drawback: If we will get new items for "Tools" in the future, we have to add it back into the menu again.

Packet vs. Frame

All over the GUI, both words are used, IMHO with the same meaning.
Unless there is a good reason not to, we should use only one of 
these words, and this consistent in the entire GUI (in all menus,
dialogs, ...). IMHO, I would prefer to use "Packet" everywhere, and
rename every appearance of  "Frame".

"Decode As" / "User Specified Decode" dialogs

There shouldn't be two menu items to trigger almost the same
functionality. This is very confusing for a normal user.
One solution could be to build something similar to the colorize
display dialog. You will see an overview of the current filters when
triggering this dialog by menu or toolbar. From there, you can push
some buttons to add/remove rules to the current decodes and such.

"Print" dialog

Currently, the user can print the current frame (without any Ethereal
specific dialogbox), or all (marked) frames in the capture file. This
is confusing when using the toolbar icon, as you don't know what will
be done before pressing the icon.

IMHO it s better to build a dialog, where the user selects which frames
he/she would like to print (using radio buttons):

• All Frame(s)
• Current Frame
• Frame(s) from xxx to yyy
• Marked Frame(s)

ToDo:

1. Group the items in the dialog using frames
2. Add a Label to the dialog: "number of frames" / "number of pages" to be printed
   
3. The common menuitems "Page Setup" and "Print Preview" should be implemented. Is this possible in GTK anyway, and how expensive is it? Any experience on this?

Capture vs. Display Filters

One of the biggest issues to solve in a usability perspective is the
"differences" in capture and display filters. It is really odd for new
users to learn two different filter "languages". For example: The
online help on capture filters is telling you: "see manual page of
tcpdump", which is difficult on a usual win32 machine :-(.

A "better than nothing" solution (and
quick to implement) would be to include the text from the
user's guide into the online help fields, for the capture and display
filters.

But of course, the clean solution would be to have just one filter
language, presumably the display filter syntax, and derive capture
filters from it. The Win32 specific Ethereal GUI "Packetyzer" http://www.packetyzer.com seems
to be doing just that. We could have a look, how they solved this topic.

Save data/settings at Program Quit

When Closing Ethereal, all things not saved are simply discarded. Your
unsaved capture file and all unsaved settings are gone. This is not the
way it should be.

Capture file

For an unsaved capture file, a dialog should come up:

Caption: "Ethereal: Capture data unsaved"
Icon: "QUESTIONMARK"
Text: "Would you like to save your capture data?"
Buttons: "Yes / No / Cancel"

• Yes: Open "Save As" dialog
• No: Simply quit Ethereal (resp. continue with next "unsaved dialog")
  
• Cancel: continue using Ethereal

If the user pushes the "Yes" button and cancels the "Save As" dialog
afterwards, simply return to this dialog!

Preferences file

For an unsaved preference file, a dialog should come up:

Caption: "Ethereal: Preferences settings unsaved"
Icon: "QUESTIONMARK"
Text: "Would you like to save your preferences settings?"
Buttons: "Yes / No / Cancel"

• Yes: Save settings into "Preferences" file
• No: Simply quit Ethereal (resp. continue with next "unsaved dialog")
  
• Cancel: continue using Ethereal
  

For "Capture Filters", "Display Filters" and "Color Filters", something
similar to the Preferences file should be done.