Re: Question on CLI vs GUI, and today's call

[Sami Wagiaalla <swagiaal@redhat.com>]

Kris,

I think that we are all very strongly agreeing here :)
> I'll try to clarify more specifically what I mean, and actual your first
> comment is the perfect lead-in for that.  Yes, indeed the UI behaviour
> (be it CLI or GUI) should not be defined by limitations of the core.
> However, equally important is that the UI should not impose limitations
> upon the core.  Nor should the UI define the functionality of the core.
> There is a fine distinction in that functionality is of course driven by
> user interaction scenarios, and user interaction defines how various
> tasks are decomposed in their individual steps, and the core has to
> provide the functionality to make those steps possible.  But that is an
> abstract concept, disconnected from specific UI design.
>
> Ultimately, the user interaction model is what drives the functionality
> that is required from the core, and the UI (CLI and GUI alike) provide
> the presentation to the user for that functionality.
>   
Agreed, and this is definitely Frysk policy. Once in a while we forget 
and we get stuck in implementation details :), but we quickly get off 
the topic and back to user goals.

One example of this is back in the day we had a button that said 
"Attach", and only when you have attached can you then go and add 
observers. Now there is only "add observer" if the core sees that an 
attach is needed in order to add that observer it does so transparently.
> To me it felt like the discussion was a mixture of abstract user
> interaction (semantics -- "what should happen if the user does blah"),
> visualization ((G)UI -- "what should this look like; should icons be
> hidden or shaded), and core functionality (implementation -- "how do we
> implement user action blah").  The first two are UI-related though at a
> very different level, and the fine line between them is very important.
>   
I think this is probably a misunderstanding the goal of the discussion 
was to figure out what the user wants so that we can use the core 
primitives in place to implement that goal.
> Mixing them up tends to lead to inconsistencies in UI between e.g. CLI
> and GUI.
>   
Agreed, if UI get too thick code should be matured, rewritten more 
generically, and then pushed down to core.
> I do agree that the discussions are very positive and constructive.  I
> do however feel that there is a tendency (as it always happens) to mix
> the areas quite a bit.  And that can be quite dangerous.
>
> Your example of the 'advance-a-line' function is a good one for this.
> As you state, there was confusion as to the exact semantics of specific
> operations, like "step" vs "advance".  The decision was to enable
> "advance" but not 'step" when a non-inner frame is selected.
This is a good example. The discussion was about what the goal of the 
user is after they have filtered through a stack of calls which they are 
not interested in, and he or she clicks "step". Do they mean go down to 
that frame which I have already dismissed and step one line ? Or 
transparently finish all those frames, arrive to the one they are 
"looking at" and step one line ? Does the use really need to be 
presented with both "step" and "advance" or can the need for both be 
eliminated by improving the concept of " the frame the user is looking at"
>   However,
> does that mean this will be implemented as a UI change?  Or a change in
> the core?  Or both?
>   
I might not be the person to answer this, but I would guess core :) In 
order to maintain the thinness of UI's, and consistency of behavior 
between them.


Cheers,
      Sami Wagiaalla