Re: [Ethereal-dev] Late feature request for 1.0

[Ulf Lamping <ulf.lamping@xxxxxx>]

Joerg Mayer wrote:
> Hello List,
>
> as we are receiving the same questions time and again I have two feature
> requests (or maybe three ;) to make Ethereal more support friendly ....
>
> 1) Get the FAQ back into the help menu
> 2) Get the start screen back and display the contents of the (unfolded)
>    help menu there.
> 3) Whenever someone selects a wireless interface on Win, display a
>    requester showing or pointing to the corresponding FAQ items.
>
> Ciao
>    Joerg
>   
Hi Joerg!

As I understand your intentions, I guess that it won't work that way 
pretty well especially for Windows users who are expecting some sort of 
"guidance" if a problem occurs. And this audience is causing most of the 
"noise" in the lists, so addressing the problems directly seems reasonable.

I agree that there is something to do before the 1.0 release on that 
topic, and I'm currently working on providing the user's guide as the 
"online help", which is a first step IMO.

Let me explain, why your suggestions are good but not enough IMHO:

1) Simply showing the FAQ in it's current text form won't be working 
well IMHO (maybe better than nothing but not more). It's an unnecessary 
mix of Unix and Windows things.Some things are unlogical (why do point 
2.1 appear under "download"?!?). It's a problem someone experience while 
*installation* appears (it's caused by the download but that's obviously 
not obvious at the moment the problem appears :-). Ok, for me and you 
the problem *is* obvious, but that's a different story, too long to be 
told here ...

I don't know if showing the FAQ will help a lot as most windows users 
(even experienced ones) might never even heard about an FAQ)!

If we want to show the FAQ, we shouldn't use ASCII text for it, as this 
just won't work!

2) Agreed. Maybe not simply the contents of the help menu (the list of 
supported protocols might not be really helpful in most cases). The 
general help topics and some "hot topics" depending on the OS might be a 
lot more interesting. On a Win32 system, a topic "Problems with Wireless 
Capturing?" might be much more helpful. This could be a link to a (new?) 
section in the user's guide or to the Wiki.

3) That would be just very annoying for most users (including me). I was 
thinking of this too, but didn't found a good trade off between annoying 
boxes and a useful feature for newbies.


I would think that at least for some problems a more "active/detective" 
approach will show much better results. For example the frequent problem 
with TCP checksum offloading and checksum errors could be automatically 
detected be the dissector. For example, if more than 0.1% of packets 
contain a checksum error (or whatever a reasonable value might be) a 
dialog box appears:

"There are a lot checksum errors in your capture. This is probably 
caused by checksum offloading. See XXX for details about this mechanism 
(O - don't show this message again)."

The dissector could simply count the checksum errors, and the GTK part 
could ask the dissector after completely loading the file/finished the 
capture.

This way, the problem will be detected "where caused", instead of: "if 
you have any problems, read all the documentation we have as this may 
solve your problem.". This is much more likely to help the user. It's 
like the help text in the dialog box "no packets captured" which seems 
to resolved *a lot* of frequently asked questions at the point where 
they appear. I can remember that there was a *huge* number of questions 
regarding this situation.

So in the end, I agree 100% that the current situation is unsatisfactory 
and *must* be fixed before the 1.0 release. However, I would think that 
some relative easy extensions can help solving the current situation a 
lot more efficient than just simply adding a lot of pointers to the help 
documentation.

Regards, ULFL