Novice user design
From Emergent
Contents |
How to better support the novice user
Overall Goals and Issues
- Target users:
- Advanced undergrad in CECN class: mostly just modifying existing models..
- Grad student in program without local modeler
- Cog neuro researcher who wants to simulate their data (on their own?? or play with model that modeling expert collaborator setup?)
- Original goal: ePrime-like usability by non-programmers: programming by lists/datatables of event types and conditions, etc.
- Key issue: with ePrime, you only have to worry about spec'ing the input -- with a model, you are also designing the brain along with the input -- and the two have to be compatible. This is a *major* departure and makes the problem much more complex. I guess this is obvious, but somehow I (Randy) was overlooking it.
- Brad's solution: make a library of parts that you mix-n-match. Kinda have that now with PBWM/PVLV, but it is not so automatic -- requires some expertise to make these parts play nice. This is a good goal, but requires a lot of scientific progress as well. This is pretty much what we had thought BICA would produce after 4 years of intensive effort..
- A more modest & perhaps realistic goal: enable experts to make models that are more easily understood and modified by non-experts. This is probably what we want to shoot for.
- providing higher-level, clearer constructs for common operations
- making it easy for experts to provide a good user interface for users (e.g. program ctrl panels), and to provide appropriate, searchable, easy-to-find documentation..
- online libraries of models and model parts -- easy to share and borrow and learn by example. need docs and search mechs etc..
- Better automatic network output decoding & visualization:
- speech output for reading models, etc
- simulated hand typing on a keyboard?? grabbing? etc? Natively support this or require Gazebo?? Yikes either way..
- Overarching implementational issues:
- programming by data (excel) vs. programming by program (perl).
- layering new stuff on top of existing "expert" system: wizards? New super-ProgEl's + custom datatable interfaces?
Some Specific Ideas
Better designer framework for input/output patterns
- named units and easy functions for activating by name (easy -- just String matrix column in data table that serves as lookup table -- existing matrix edit guy is probably OK for this)
- drag-n-drop decoders for output units?? -- these bits are phonemes, these are motor movement vectors.. hmm...
- ability to plop an image (with suitable pre-processing) right into some layer? but this would require a model capable of actually processing images...
Datatable-driven programs
- Novice users will program primarily by creating lists of things that they want to happen. Tom's project is a good example. We need to come up with a good design for this, and figure out how to layer this cleanly on top of what we have now.
- Tom's project (PFC Mega model) -- how far can we get with datatables?
- one datatable with enumerated values of each of the input units (cols: Layer, Unit, Name) -- wizard to design this?? Need groupings of same names ("slots"), etc
- function that takes a Name and activates corresponding unit in input_data table (basic primitive)
- lists of valid choices of Names for a given trial type
- lists of trial types..
- key challenge: coordinating all the lists and expressing all the interactions. is it easier just to write the damn program??
- new plan: introduce key high-level primitives to make the programs as easy as possible. the unit map table + some basics for organizing condition types. then programs are simple glue that directly expresses expression logic.
Documentation Wiki
(Dave) I continue to believe that documentation/tutorials are the key here. No matter what features you add, having resources that explain how to do things is critical. A Emergent documentation wiki would document the system generally, document each Method in detail, provide tutorials for various types of activities, document each model and Program in the library, etc. Importantly, it would grow and improve over time and would make it easy for students and other users to add their own thoughts and comments that might help explain something to novice users. A wiki approach would make it easier for the doc to be managed and improved by all of us, rather than having a single document that someone has to coordinate.
Initially, it would be important to create some structure in it so that the overall organization is what we desire.
Various points from lab meeting 2/6/07:
1. The current version is specifically not supposed to be for the beginner, and is just about getting the underlying "expert" guts all working and debugged, with the assumption that beginner stuff will layer on top if it. 2. Wizards etc will naturally layer on top and are relatively straightforward, and we should start designing this at some point in a month or two, after the beta release. 3. However, I do think we should consider some important infrastructural issues that might facilitate better access to the existing stuff, along the lines of Brad's comments toward the end. We need to decide about this stuff sooner rather than later, because it will require redesign of existing code instead of just layering on later.
- It should be easier for people to interact with and "consume" programs written by others.
- A key first step is having the default panel for an individual program be the "control panel" view, which is just the objs, vars, and args. I suppose we can keep the code there but have it not-expanded by default. However, I do think this might just be confusing and inviting inappropriate fiddling. Yes, we might want to have context-specific HIDDEN in trees. So, the idea is to have 3 panel views: Control panel (default), program editor, and properties.
- The control panel should only show the actual value parts of variables, not all the type and other configuration stuff that goes into setting them up. Ideally, these would be editable in place instead of the click-to-edit spreadsheet style thing.
- Also need to make it easier for all key parameters to be represented in the control panel. A good example is the SEQUENTIAL vs. PERMUTED thing in the BasicDataLoop (came up in lab) -- we need to have a pointer to that parameter somehow as a top-level variable..
- I'm not sure the previous plan for a program-group level control panel thing is all that useful (too much information!), after having used things a bit more, but it would be easy to make it just a list of these individual program control panels..
- programs should be more robust in self-configuring, and/or contain their own "configure me" wizard-like thing. as it is now, we are relying on the pointer resolution code of the dump load system to configure a previously-saved program when it is loaded into a new project. This is not good.
- If the above control panel is in place, then all the key parameters that need to be set should be there. Anything that is NULL should be highlighted. A "conforming" program should be designed such that when these params are set, everything works.
- robustness: in the CycleMonitor program example from today, I changed the name of a variable, but this was not updated in the args to various functions, because those are stored as text. A long-standing todo is to improve the way that these args work, so that they can be var pointers instead of just strings. A strong constraint would be to make them *only* be var pointers or literals (int, string, float, enum val). If you want to make a calculation involving a variable, then you need to do that as a separate step before-hand that creates a new variable, that is then passed as an arg. One could also imagine various variable name search & replace mechanisms. Probably we'll need to do this search & replace in any case because we need to have abritrary text expressions somewhere. So, whenever a variable name is changed, the datachanged thing can just go through and do a replace-var-name call on all prog els, with previous-name and new-name, and each can handle it in their own special way.
Dave comment
I think the idea that "novice users" will modify programs is simply a wrong premise. Novice users shouldn't have to modify programs, and in general people who are not programmers or at least pretty savvy with macros or similar will simply not be able to do it. I'm thinking of most people from neurosci/cogsci who take the modeling class, for example.
If by "novice users" you mean experienced Leabra 3.2 users who are learning 4.0, then although there are plenty of improvements one could make in the software, it is mainly a matter of setting up appropriate training and tutorials. Rather than diving into the first problem someone suggests "because you can," it would be better to methodically cover the various key aspects of programs, just like any other language would be covered (e.g., control structures like loops/if-then; arguments; method calls, etc.).
Tom comment(s)
24Apr07
- I think the idea of having a (growing) library of online models that are modifiable by new users is *exactly* the right way to go. To this end, I wanted to mention a great idea that Phil expressed to me in discussion several weeks ago: Why not take all of the models in the current textbook (CECN00) and divvy them among the lab members for porting to the Emergent platform? Not only would this help Randy and Yuko towards a 2nd edition, it would be a great way for all of us to get up to speed on Emergent! (Dave)Great idea!
- Following on Dave's points about not expecting novices to program, and thinking in terms of new users modifying existing models, it seems one way to do that would be to define a limited set of "permitted" modification paths for each model that would have built in compatibility checks along the way to prevent "breaking the model." This may not be realistic, but it would seem to help promote adoption by helping assure success early for new users. (Dave) Or in the documentation on the model, describe the parameters and program components that make sense to change.
- As a path to the last bullet point, maybe we could promote a kind of collaboration community between new users and the expert designers of the original model; the latter being available as a "help desk" to assist the former in their modifications. Thus, the first few attempts to modify a given model would serve for the expert to define the permittable paths by putting in compatibility checks, etc. for the things that the new user wants to do, generalizing from those issues as suggested/desired. (Dave) wikiwikiweb
