Conference bulova::decw_jan-89_to_nov-90

    Please elaborate as to the audience for these videos.
    
    Thanks
    
    Andy

    
    The audience is programmers - either internal or external.
    
    Likely to be used by support people as well as developers.

    I would suggest that these are too disparate an audience.
    
    Remedial support folks do not need the same type of training as
    developers, exepting the case of a very broad overview, which in
    DECWindows case would take about 60 seconds.
    
    Separate the audiences:
    
    	o Support folks need remedial advice, hints on problem solving and 
    	  common mistakes/misapprehensions;
    
    	o SW(A)S folks and developers need programming hints, example programs 
          and how to best use them, shortcuts and clear documentation.
    
    Videos should therefore reflect these needs....
    
    - Andy

    
    for the programming audience I would first generate an architectural
      overview of DECWindows in general, and then UIL, TOOLkit, and X
      layers.  Show them how they interact, define a suggested/required
      order in which pieces are put together.
    
    Then have several tapes that build applications - very small at first.
       then bigger and bigger adding different features as they go.  Have
         the tape in a series so that you add features to the same original
    	   program ...
    
    Also give a tape on the documentation and the supposed "threads" from
      one piece of documentation to another.
    
    keep it simple - so many levels of programmers can benifit from it.  
      Provide soft copy of the user's system of the software at different 
        stages in the tapes.  Build an entire package.
    
    Do lots of "hand holding" because programming in DECWindows can be VERY
      frustrating ( personal experience )
    
    my 2 cents ... Jim Krieger, VMS Performance Tools
    

    RE: .4 Architecture would certainly be useful to area-level FS too.
    
    Andy

    I'd go easy on the architecture at the start.  I was exposed to X and
    DECwindows early on and the approach was primarily architectural.  I
    completely lost it.  I had to work my way in from the other end (the
    practical approach via example and word of mouth) and then pick up the
    architecture a bit at a time to tie everything together.
    
    The functions of DECwindows can be understood in terms of things that
    many, if not most, programmers can relate to.  Personally, I found the
    architecture of X (et al) to be quite alien.
    
    For the toolkit, I'd hilight the interaction between the application
    and the widgets it's dealing with.  In other words, the callback
    mechanism and the dos and don'ts in that area.
    
    For XLIB, I'd go by examples.  Many programmers are now familiar with
    packages like UIS and X at the level of drawing circles, creating
    windows and the like.  Don't throw all the window hierarchy crap at
    them from the very start.  Start simple and expand on the basics.  I'm
    sure this is obvious to those putting together the training materials,
    but it certainly wasn't to the people trying to tell us how things
    worked in the early going.
    
John

I think that .6 ran into a typical problem with early training in a new
system.  The early training was taught by engineers not teachers.  And, it
misguessed the audience.  Most of the training available early on focused
on the architecture because that was what was new and different.  It is
very easy to fall into the trap of thinking that "drawing a line is drawing
a line".

Dick

    Please consider performance hints and kinks.  At the very least, raise
    the awareness that the toolkit does a lot for the programmer, but it
    doesn't happen for free.  For example, the more widgets and windows you
    use, the more memory you need...
    
    There are a number of trivial sounding but not-exactly intuitive
    performance trade-offs:
    
    	Widgets are more flexible, but gadgets use less memory
    
    	Windows that get decorated by a window manager (e.g. dialog boxes) 
    	are more expensive than windows that don't (e.g. menus).  Window
    	management provides added features -- for a price
    
    	There are a few ways (4?) of doing mouse tracking.  Sometimes one
    	way is more appropriate than another.  (The four I can think of
    	are: (1) turn on MotionNotify events and process them as fast as
    	possible, (2) turn on MotionNotify hints, then do a GetPointer to
    	reset the hint and get the latest position, (3) turn on MotionNotify 
    	hints, use the position from the MotionNotify and do a GetPointer
    	just to reset the hint, (4) turn off MotionNotify and use
    	EnterNotify and LeaveNotify events.) 
    
    
    John B.

Re. 2 
> The audience is programmers - either internal or external.
> Likely to be used by support people as well as developers.

I think the training requirements for SWAS people who will be providing
technical consultancy (NOT contract programming) to customers and the
training requirements for external DECwindows programmers are so similar
that they are worth considering together.

First a point of clarification, certainly for SWAS in the UK there is 
a distinction between pre-sales and post-sales work. I am talking about 
post-sales work, the stuff that gets paid for (at rates that would make
me rich very quickly if I got it all :-) and demands that the SWAS 
consultant has in depth programming credibility with the customer.

For the training requirements....

I would like to see the training encompass not only programming but
application architecture. I don't mean architecture in the sense Xlib is
connected to the Intrinsics and the Intrinsics is connected to the Toolkit
and the Toolkit..... I would like to see training covering how to build a 
distributed DECwindows based application, how it can relate to the features 
of a LAVC, how resilience can be catered for, how to make it manageable 
etc.

As far as the method is concerned, as the idea is to provide this training
on videos, hands on is a bit of a problem, but it is important to provide 
examples. That may seem obvious, but instead of treating the training as 
having to adopt either one of two approaches as .6 and .7 seem to imply why 
not mix examples with architecture. Both are important and one relates to 
theory and the other to practice. It is known that all humans learn by 
intaking a bit of theory, then testing it out, learning from the mistakes 
in their understanding, then taking in more theory and round and round 
again. The videos should respect this approach.

Lastly, I have introduced and loosely trained a number of customers and 
all seem to have benifited from the alternating theory/example method.  

Mike Collins, at the coalface in London.

    
    re .9
    
    >>> It is known that all humans learn by intaking a bit of theory,
    >>> then testing it out, learning from the mistakes in their 
    >>> understanding, then taking in more theory and round and
    >>> round again.  The videos should respect this approach.
    
    Let's be reasonable.  Not all humans do anything in the same way,
    and that includes learning.  Some people do better with all the
    concepts in place, and others can do without the theory until
    after they've been practicing for a while.  Many, of course,
    learn as you have described.
    
    Overall, your points are well-taken.  It is important, however,
    to allow for diverse styles of learning and presentation of
    materials.
    
    John Hoffman
    ULTRIX DECwindows Engineering
    
    
    
                   

Somewhere you should build a simple widget since that's the only way 
you'll ever explain what one is.  

Also, being at the CSC I guess I'm "remedial support" which, contrary
to an earlier note, needs to know programming as well as support
hints/kinks.  Often a customer's difficult how to question is caused
by bad design.  Only if we also know programming well can we give the
customer the guidance they really need.