Assistant refinement

Assistant refinement

[Sami Wagiaalla]

Yet another assistant refinement suggestion:

My comment on http://sourceware.org/bugzilla/show_bug.cgi?id=4149:

I have a few suggestions to solve this, and the Quick Debug button problem.
Doing screen shots its time consuming so I will try to describe it verbally and
people feel they need screen shots, I throw some together.

[1] Merge Session Manager into the Assistant so that it becomes page 1
[2] At the bottom *always* have present a next, back, and finish (start?)  
    button.
    clicking the finish button takes you directly to frysk with the default or
    the previously saved settings
[3] Page 2 of the session is a page which enables the user to choose from a 
    Traditional debugging session or a Monitoring Session, something like what   
    is in the attached screen shot 
    (http://sourceware.org/bugzilla/attachment.cgi?id=1629&action=view <http://sourceware.org/bugzilla/attachment.cgi?id=1629&action=view>).
    My feeling is that this should only effect what window (source or monitor)
    is presented first, and that the user can always switch between the modes
    even after the session has been started.

The rest of the pages remain the same. Thoughts ?

Re: Assistant refinement

[Sami Wagiaalla]

correct link to the bug:

http://sourceware.org/bugzilla/show_bug.cgi?id=4149

Re: Assistant refinement

[Andrew Cagney]

Sami,

I'm not sure I'm following here ; merge what part of the session manager 
and the assistant?  What does a user see first?

Re-starting a session, which I think is the common case, is already 
pretty slick.  For instance, double click on "Debug bash" gets the 
proc-picker, and "finish/debug" gets the debugger for those processes.  
So I'm not sure how the assistant and session manager can be merged.  
The session manager lets the user control / select / [edit] / re-start / 
[eventually] resume sessions, creating a new session is just one 
sub-task from that window.

Looking at 
http://sourceware.org/bugzilla/attachment.cgi?id=1629&action=view it is 
roughly what was described, the HIG also has a good example of the 
initial screen and guidelines:
-> there should be a heading and summary paragraph explaining what is 
going on - big picture
-> the choices should have short single sentence descriptions
-> no apply button :-)
If "debug", the session would be called "Debug ...",  the event-picker 
can be skipped, "start debugger" ("debug"?) (replaces finish) jumps to 
source window ;; for "monitor", the session would be called "Monitor 
...", the event-picker is included in the sequence, and "start monitor" 
("monitor"?) (relaces finish) jumps to the monitor.

However, this assumes that there continue to be separate monitoring and 
debugging windows.  Ideas are still bouncing around for that one.  
Regardless the "qick debug" button should be on the left.

Andrew

Sami Wagiaalla wrote:
> Yet another assistant refinement suggestion:
>
> My comment on http://sourceware.org/bugzilla/show_bug.cgi?id=4149:
>
> I have a few suggestions to solve this, and the Quick Debug button 
> problem.
> Doing screen shots its time consuming so I will try to describe it 
> verbally and
> people feel they need screen shots, I throw some together.
>
> [1] Merge Session Manager into the Assistant so that it becomes page 1
> [2] At the bottom *always* have present a next, back, and finish 
> (start?)     button.
>    clicking the finish button takes you directly to frysk with the 
> default or
>    the previously saved settings
> [3] Page 2 of the session is a page which enables the user to choose 
> from a    Traditional debugging session or a Monitoring Session, 
> something like what      is in the attached screen shot    
> (http://sourceware.org/bugzilla/attachment.cgi?id=1629&action=view 
> <http://sourceware.org/bugzilla/attachment.cgi?id=1629&action=view>).
>    My feeling is that this should only effect what window (source or 
> monitor)
>    is presented first, and that the user can always switch between the 
> modes
>    even after the session has been started.
>
> The rest of the pages remain the same. Thoughts ?
>
>

Re: Assistant refinement

[Sami Wagiaalla]

I am suggesting this:

user starts up frysk:

[1]
A page pops up with a list of previous sessions the buttons new and 
delete to the side.
in the bottom the buttons [next] and [finish].
clicking [finish] at any point starts the monitor/debugger depending on 
was was saved from before.
this enables the user to select the session and start it in two clicks.

user clicks next/new

[2]
they see the page currently referred to as the process picker.
In the bottom the buttons [back] [next] [finish]

user clicks next

[3]
they see this: 
http://sourceware.org/bugzilla/attachment.cgi?id=1629&action=view
(maybe here if they choose "debugging" (should be Debuging Session :)) 
then next is disabled)

user clicks next

[4]
they see observer picker

This stream-lines the process, eliminates extra clicks when restarting 
an old session, eliminates loops and branches in the story board, and 
eliminates the quick debug button.


Andrew Cagney wrote:
> Sami,
>
> I'm not sure I'm following here ; merge what part of the session 
> manager and the assistant?  What does a user see first?
>
> Re-starting a session, which I think is the common case, is already 
> pretty slick.  For instance, double click on "Debug bash" gets the 
> proc-picker, and "finish/debug" gets the debugger for those 
> processes.  So I'm not sure how the assistant and session manager can 
> be merged.  The session manager lets the user control / select / 
> [edit] / re-start / [eventually] resume sessions, creating a new 
> session is just one sub-task from that window.
>
> Looking at 
> http://sourceware.org/bugzilla/attachment.cgi?id=1629&action=view it 
> is roughly what was described, the HIG also has a good example of the 
> initial screen and guidelines:
> -> there should be a heading and summary paragraph explaining what is 
> going on - big picture
> -> the choices should have short single sentence descriptions
> -> no apply button :-)
> If "debug", the session would be called "Debug ...",  the event-picker 
> can be skipped, "start debugger" ("debug"?) (replaces finish) jumps to 
> source window ;; for "monitor", the session would be called "Monitor 
> ...", the event-picker is included in the sequence, and "start 
> monitor" ("monitor"?) (relaces finish) jumps to the monitor.
>
> However, this assumes that there continue to be separate monitoring 
> and debugging windows.  Ideas are still bouncing around for that one.  
> Regardless the "qick debug" button should be on the left.
>
> Andrew
>
> Sami Wagiaalla wrote:
>> Yet another assistant refinement suggestion:
>>
>> My comment on http://sourceware.org/bugzilla/show_bug.cgi?id=4149:
>>
>> I have a few suggestions to solve this, and the Quick Debug button 
>> problem.
>> Doing screen shots its time consuming so I will try to describe it 
>> verbally and
>> people feel they need screen shots, I throw some together.
>>
>> [1] Merge Session Manager into the Assistant so that it becomes page 1
>> [2] At the bottom *always* have present a next, back, and finish 
>> (start?)     button.
>>    clicking the finish button takes you directly to frysk with the 
>> default or
>>    the previously saved settings
>> [3] Page 2 of the session is a page which enables the user to choose 
>> from a    Traditional debugging session or a Monitoring Session, 
>> something like what      is in the attached screen shot    
>> (http://sourceware.org/bugzilla/attachment.cgi?id=1629&action=view 
>> <http://sourceware.org/bugzilla/attachment.cgi?id=1629&action=view>).
>>    My feeling is that this should only effect what window (source or 
>> monitor)
>>    is presented first, and that the user can always switch between 
>> the modes
>>    even after the session has been started.
>>
>> The rest of the pages remain the same. Thoughts ?
>>
>>
>

Re: Assistant refinement

[Andrew Cagney]

Sami Wagiaalla wrote:
> I am suggesting this:
>
> user starts up frysk:
>
> [1]
> A page pops up with a list of previous sessions the buttons new and 
> delete to the side.
> in the bottom the buttons [next] and [finish].
> clicking [finish] at any point starts the monitor/debugger depending 
> on was was saved from before.
> this enables the user to select the session and start it in two clicks.

No.  "next" is part of an assistant, and the Session Manager is not an 
assistant.  The Session Assistant is for either creating a "new" 
session, or picking and [re-]"open"ing an existing session.  In the case 
of re-opening an existing [monitoring] session, the operation is 
expensive and potentially fatal, the user needs to be presented with a 
check-point confirming what's about to be monitored so that they can 
confirm it.  That means at minimum of double-click, click.

If the desire is just to reduce the mouse-click count then there are 
better ways of doing this.  For instance:

- debug session of a "new process" doesn't need process-picker and/or 
observer-picker.  For it "open" jumps to the source code window, starts 
the process and runs it to main().

- let the user explicitly edit the session so that it skips the p-p 
window.  When combined with specialized logic, it would let the user 
quickly monitor specific processes based on an arbitrary criteria.  For 
instance, a session to "Monitor the top 2 processes".


>
> user clicks next/new
>
> [2]
> they see the page currently referred to as the process picker.
> In the bottom the buttons [back] [next] [finish]
>
> user clicks next
>
> [3]
> they see this: 
> http://sourceware.org/bugzilla/attachment.cgi?id=1629&action=view
> (maybe here if they choose "debugging" (should be Debuging Session :)) 
> then next is disabled)
>

Assuming the differentiation between debugging and monitoring remains, 
then I think this question should be asked up front.  That way the the 
first thing the user is presented is:

-> a summary of what is happening

-> a question as to what they want to be doing initially

That way the user gets a warm-fuzzy that frysk "knows" what they want 
and is being customized for that need.  With out that up-front question 
one is wondering: "where is this going?", "what is this doing?".

To give an example, consider connecting a machine to a network.  As a 
user, you have an ethernet cable in one hand and the lap-top in the 
other.  The first question you expect is: "which network type?" 
"eithernet", "wireless", "modem", ... ;; and not "is this using dhcp?" 
say - "DHCP for what"?

Andrew