[LON-CAPA-dev] lonparmset

Mark Lucas lon-capa-dev@mail.lon-capa.org
Mon, 25 Feb 2002 07:47:18 -0500 (EST)


Hi-

	Thanks for the input over the weekend. I thought it might be good
for me to drop to the list a quick description of what Robert and I are
looking to do with lonparmset in the near term future.

	I think there are a couple of problems with parmset that make it
cumbersome for typical use. These are basically coming from my own
observations and biases. If there is any body of feedback regarding this
page from other places, please let us know!!! 

(1) One needs to know 'the rules' and have available a 'part 0' resource
in order to set defaults for a map

(2) As far as I have been concerned, 95% of the time I'm setting the
critical details for a map, not for a specific problem. Our paradigm here
is that an assignment is a page. I presume most people also work with a
group of problems being due simultaneously.

(3) The amount of information and scrolling is cumbersome. I believe that
the map default information should be available concisely at the top of
the page.

(4) The large number of columns can be cumbersome.

(5) The part ID language is not necessarily intuitive to anyone but the
  author, and even not the author sometimes.
  If I create a problem with two parts and publish it, the parts get
  id numbers, for example 14 and 16. These don't mean much to a typical
  user. They mean even less if I now go in and insert an extra part at the
  beginning, because the publisher will automatically assign another
  number, like 18. So now, the three parts to the problem are 14,16,and
  18.



What we are going to try to implement is the following:

* Underneath the selection boxes (the top set of options), the first
   thing to appear will be a set of default boxes for each map selected.
   Typically this will be only for one map, but if all maps are selected,
   each map will have a line, or short table.

   Nominally, this table will allow one to set 'the major' default options
   'for this map' in one localized area.

   For me, the 'the major' defaults would be open date, due date, answer
   date, number of tries, and default tolerance. This, of course, presents
   some bias. It might be more reasonable to give any of the resources
   found within the map.

* Underneath this default region will be a listing of all problems with
   appropriate parameters and columns listed.

* Robert's idea was to allow one to then check which parameters are
  important on a problem-by-problem basis. For example, with the default
  information above, you would then only want sig figs, tolerance, and
  points listed for each problem. Thus the check list and multiple pscat
  values.

* There will be an extra selection box - this will chose a brief or full
   display. The brief display would provide only the 'for this resource'
   columns, the resource defaults, and the final value in place.
   The full display would give the 'for this course' and 'for this map'
   columns as well.

* If one then chooses a particular section:
    The top portion becomes defaults 'for this map, for this section'.
    An extra section column or columns are added to the lower part.

* If one then chooses a particular student:
    The top portion becomes defaults 'for this map, for this student'.
    An extra student column or columns are added to the lower part.

We believe these steps will partially address the issues above. I'm not
sure it would yet pass muster with a 'typical instructor', but it may come
closer.

It does not address my concern with the labelling of resource parameters,
and I'm not sure how we can. What I think would be better is that the
parameters are referenced (at least in the interface), as resource,
part(1,2,3,4,...), answer(1,2,3,4,...). I know the format is such because
there may be multiple answers per part (ANDs and ORs) and multiple parts
per problem. I'm not sure the underlying IDs need to change, but I do
think the abstraction presented to the instructor needs to be more
understandable.

Okay - how's that for an early morning core dump. I'm sorry about the
length. As you can tell, Robert and I are into the code at this point, and
any feedback you can give regarding our short-term redesign goals would be
greatly appreciated!

					Later,
					   Mark
----------------------------------------------------------------------------
Mark Lucas					email: lucasm@ohiou.edu
252D Clippinger Lab  				phone: (740)597-2984
Department of Physics and Astronomy             fax:   (740)593-0433
Ohio University
Athens, OH 45701