| * replaceafill goes to the grocery store | 00:22 | |
| *** replaceafill has quit IRC | 00:27 | |
| *** menesis has quit IRC | 00:42 | |
| *** th1a has quit IRC | 00:48 | |
| *** th1a has joined #schooltool | 01:48 | |
| *** mattva01 has quit IRC | 02:14 | |
| *** mattva01 has joined #schooltool | 02:15 | |
| *** alga has quit IRC | 03:29 | |
| *** th1a has quit IRC | 03:55 | |
| *** aks has joined #schooltool | 06:21 | |
| *** aks has joined #schooltool | 06:21 | |
| *** yvl has joined #schooltool | 07:10 | |
| *** aks has quit IRC | 07:48 | |
| *** aks has joined #schooltool | 07:48 | |
| *** paulproteus has quit IRC | 09:31 | |
| *** paulproteus has joined #schooltool | 09:33 | |
| *** aks has quit IRC | 09:43 | |
| *** alga has joined #schooltool | 09:53 | |
| *** aks has joined #schooltool | 10:24 | |
| *** menesis has joined #schooltool | 10:32 | |
| *** menesis has quit IRC | 12:00 | |
| *** povbot has joined #schooltool | 12:22 | |
| *** menesis has joined #schooltool | 12:51 | |
| *** yvl has quit IRC | 13:02 | |
| *** menesis has quit IRC | 13:42 | |
| *** menesis has joined #schooltool | 13:51 | |
| *** aks has quit IRC | 14:16 | |
| *** ignas has joined #schooltool | 14:49 | |
| *** yvl has joined #schooltool | 14:59 | |
| *** th1a has joined #schooltool | 15:15 | |
| *** replaceafill has joined #schooltool | 16:28 | |
| th1a | hi aelkner_, replaceafill. | 16:31 |
|---|---|---|
| th1a | yvl, | 16:31 |
| yvl | hi | 16:31 |
| aelkner_ | morning | 16:31 |
| replaceafill | good morning/afternoon | 16:31 |
| th1a | I think yvl has the floor. | 16:35 |
| yvl | I pushed some changes to the main branch | 16:35 |
| yvl | way less than I'd like to, but... well... | 16:35 |
| yvl | in any case | 16:35 |
| yvl | there are layer creation views, and that's it | 16:35 |
| yvl | so the next thing is to add "node" creation views | 16:36 |
| yvl | I imagine, if one creates layers called "Program", "Area" and "Course" | 16:36 |
| yvl | *somewhere* there should be an *Add* box in sidebar | 16:37 |
| yvl | with three links | 16:37 |
| yvl | "Program", "Area", "Course" | 16:37 |
| yvl | that opens a node creation view, and when it's created, assigns the correct layer to it | 16:37 |
| yvl | there could also be relationship-style view for the node: Edit Layers | 16:38 |
| yvl | what else... | 16:39 |
| yvl | when looking at a Node, there could also be an *Add* box | 16:39 |
| th1a | Is there anything else that you didn't push that could be useful as a reference? | 16:39 |
| yvl | sorry, no | 16:39 |
| th1a | Just wondering. | 16:40 |
| yvl | basically, in that Add box, there should be links, computed like this: | 16:40 |
| yvl | take layers of the node, for each layer collect direct child layer relationships, and list them in the *Add* box | 16:41 |
| th1a | Can we get an instance of this up and running? | 16:41 |
| yvl | so if "Area" is a subset of "Program" | 16:41 |
| yvl | and go to "Program" | 16:41 |
| yvl | add a "program" node, like "ITC" | 16:42 |
| yvl | and look at ITC | 16:42 |
| yvl | in it's *Add* box, there should be a link "Area" | 16:42 |
| yvl | you click it, opens the node creation page | 16:43 |
| yvl | when created, it links it's layer to "Area" | 16:43 |
| yvl | (say, you created "Web") | 16:43 |
| yvl | and it also links it's parent node to "ITC" | 16:43 |
| aelkner_ | yvl, I think the Layers link on the School tab should have the year/layers in the url | 16:43 |
| aelkner_ | and get ILayerContainer index.html view to work like /layes does now | 16:44 |
| aelkner_ | that way, the Done button would work on a specific layer | 16:44 |
| yvl | hmm, lemme look | 16:44 |
| yvl | ok, the answer is *no* | 16:46 |
| aelkner_ | or you could code a custom done class | 16:46 |
| yvl | yes, same as Groups | 16:46 |
| yvl | and everything else | 16:46 |
| yvl | I still maintain that adding ?schoolyear_id=XXX notation was not a good idea | 16:47 |
| yvl | but yes, there are some rough edges that need polishing | 16:47 |
| yvl | like breadcrumbs | 16:47 |
| aelkner_ | well, if we use things like /groups and /layers as the urls, then we need it | 16:47 |
| yvl | they're done for skills, but not for layers | 16:47 |
| aelkner_ | we didn't need to have done that | 16:47 |
| yvl | half a year ago | 16:47 |
| aelkner_ | yeah, then | 16:48 |
| aelkner_ | we could have had the traversal to the actual year's container there | 16:48 |
| yvl | somebody took a shortcut | 16:48 |
| replaceafill | my bad :( | 16:48 |
| yvl | no, it's not your bad replaceafill | 16:48 |
| yvl | anyway | 16:48 |
| aelkner_ | yeah, it is what it is, and we will have to deal with it the way it is | 16:49 |
| yvl | right | 16:49 |
| yvl | it's not that bad anyway | 16:49 |
| yvl | so... | 16:49 |
| yvl | what would you like me to talk about | 16:49 |
| * yvl has trouble deciding :) | 16:50 | |
| aelkner_ | what's left to get it all tied together | 16:50 |
| replaceafill | th1a, http://69.164.203.135:6665 current schooltool.cando trunk | 16:51 |
| yvl | well: | 16:51 |
| yvl | node creation | 16:51 |
| th1a | thanks replaceafill. | 16:51 |
| yvl | skillset assignement to nodes | 16:51 |
| aelkner_ | i mean, once you've created nodes, the vews that you will be doing next, how does the user see it all tied together? | 16:51 |
| yvl | node "deployment" to courses | 16:51 |
| yvl | and reasonable searches / browsing everywhere | 16:51 |
| aelkner_ | that's another way of saying assigning comps to courses, right? | 16:52 |
| yvl | yes | 16:52 |
| yvl | now, you can assign a skillset from a global list | 16:52 |
| yvl | that sucks | 16:52 |
| aelkner_ | once that is done, then the teacher will see the comps in the gradebook? | 16:52 |
| yvl | we need to browser through nodes, and find a correct one | 16:52 |
| yvl | collect it's child nodes recursively and their skillsets | 16:52 |
| yvl | and put those skillsets to the course | 16:53 |
| yvl | aelkner_, the teacher should be able to see the *skills* in the gradebook | 16:53 |
| yvl | once *skills* gradebook is done | 16:53 |
| aelkner_ | but those are the course assigned skills, right? | 16:53 |
| th1a | replaceafill: Incidentally I get this on Chromium: Error 312 (net::ERR_UNSAFE_PORT): Unknown error. | 16:53 |
| yvl | and skillset deployment to the course is done | 16:53 |
| th1a | A DONE/NOT DONE list might save a lot of confusion. | 16:54 |
| replaceafill | th1a, :| | 16:54 |
| replaceafill | th1a, let me change the port | 16:54 |
| th1a | It works for firefox. | 16:54 |
| replaceafill | ah ok | 16:55 |
| yvl | the point being, those are separate problems | 16:55 |
| aelkner_ | yvl, how is skillset deployment to course acheived by the user? | 16:55 |
| yvl | ttw :D | 16:55 |
| yvl | sorry, kidding | 16:55 |
| yvl | but yes, go to course | 16:55 |
| yvl | go to skills | 16:55 |
| yvl | click assign | 16:55 |
| yvl | (you'll have to go to School -> Skills and create a skillset first) | 16:56 |
| aelkner_ | so, that confuses me | 16:56 |
| yvl | I see that | 16:56 |
| aelkner_ | if all the user needs is global (app context based) skillsets and a course | 16:56 |
| aelkner_ | what are the nodes and layers for then? | 16:57 |
| aelkner_ | and how would the user see them from the course assign views? | 16:57 |
| yvl | through relationships | 16:57 |
| aelkner_ | in the ui, i mean | 16:57 |
| yvl | skillsets are supposed to be linked with nodes | 16:57 |
| aelkner_ | ah | 16:58 |
| aelkner_ | so even though the user is selecting a global skillset | 16:58 |
| aelkner_ | the code behind it would look for the matching node in the given school year | 16:58 |
| aelkner_ | and match it up that way? | 16:58 |
| yvl | well | 16:58 |
| yvl | the current way, of adding a global skillset | 16:58 |
| yvl | was done so that replaceafill could start working on the gradebook | 16:59 |
| yvl | and partly because this is enough | 16:59 |
| yvl | to have the cando-style gradebook | 16:59 |
| yvl | some people may need not program areas and all that hassle | 17:00 |
| yvl | and your job will be adding UI to browse to the correct node and add all it's skillsets to the course | 17:01 |
| yvl | and then - yes | 17:01 |
| yvl | the code behind it should match it up | 17:01 |
| aelkner_ | so, you're saying that what we have for course assign skills using global skillsets is only temporary | 17:01 |
| aelkner_ | to help wth demoing replaceafill's gradebook, right? | 17:01 |
| yvl | yes, unless th1a decides to keep it | 17:02 |
| yvl | keep in mind, that global skillsets are per-application; nodes however are per-year | 17:02 |
| yvl | basically saying - these skillsets matter this year | 17:02 |
| aelkner_ | yeah, well, i know that as well as anyone, having done the import/export | 17:03 |
| aelkner_ | that's why i've been asking these questions | 17:03 |
| yvl | of course | 17:03 |
| yvl | hence "keep in mind" part ;) | 17:03 |
| yvl | btw | 17:04 |
| yvl | nodes have a method: findPaths | 17:04 |
| yvl | they return a list of possible "paths" of nodes | 17:04 |
| yvl | so - a list of lists | 17:04 |
| yvl | usually, there will be only one path | 17:05 |
| yvl | but if you set up two document models - like industry versus education | 17:05 |
| yvl | you will have two paths for some nodes | 17:05 |
| yvl | also, to keep in mind, | 17:05 |
| yvl | a skillset may belong to many, many nodes | 17:06 |
| *** replaceafill has quit IRC | 17:06 | |
| yvl | say... "Work place habits" skillset | 17:06 |
| th1a | I think we're going to pretty much completely re-organize this. | 17:06 |
| yvl | they have that in VERSO - or similar | 17:06 |
| th1a | As it is presented through the web. | 17:06 |
| yvl | ok | 17:06 |
| th1a | Essentially, the web-based entry can focus on a subset of what is possible through the model. | 17:07 |
| yvl | true | 17:07 |
| th1a | And thus be actually comprehensible to the likely users. | 17:07 |
| *** replaceafill has joined #schooltool | 17:08 | |
| replaceafill | sorry, got disconnected | 17:08 |
| yvl | welcome back :) | 17:08 |
| aelkner_ | we thought you left on purpose :) | 17:08 |
| replaceafill | :D | 17:08 |
| th1a | We support crazy bullshit for CanDo that never should have been required in the first place. | 17:08 |
| yvl | I'm pretty sure you guys will work the UI part out quite well | 17:08 |
| th1a | So basically the ttw approach will assume a higher level of sanity. | 17:09 |
| th1a | So from the users point of view they're entering a skills document. | 17:09 |
| th1a | They have to define its structure, | 17:10 |
| th1a | (layers?) | 17:10 |
| yvl | (yes) | 17:10 |
| th1a | and then create nodes, | 17:10 |
| th1a | and finally skills? | 17:10 |
| yvl | yes | 17:10 |
| th1a | Skillsets are always the layer above skills? | 17:10 |
| yvl | no | 17:10 |
| yvl | then create nodes | 17:10 |
| yvl | then create skillsets | 17:10 |
| yvl | and create skills in skillsets | 17:10 |
| th1a | node - node - node - skillset - skill | 17:11 |
| th1a | (for example?) | 17:11 |
| yvl | yes | 17:11 |
| yvl | the idea is, that once you have defined layers, you can present that to the user as | 17:11 |
| yvl | Program - Area - Course - skillset - skill | 17:12 |
| yvl | so I don't know if the word "node" will be in UI at all | 17:12 |
| th1a | RIght. | 17:12 |
| th1a | And which of this is defined per year? | 17:12 |
| yvl | layers and nodes are defined per-year | 17:12 |
| yvl | skillsets (with their skills) are global | 17:13 |
| *** replaceafill has quit IRC | 17:13 | |
| *** replaceafill_ has joined #schooltool | 17:13 | |
| *** replaceafill_ is now known as replaceafill | 17:13 | |
| yvl | I mean ideally if a course like 7th grade algebra | 17:14 |
| yvl | is a stable one (as in does not change for 3 years) | 17:14 |
| yvl | I'd like that it used the same skillset objects | 17:14 |
| yvl | in all 3 years | 17:14 |
| yvl | just because there's a LOT of skills in CTE db | 17:14 |
| th1a | I'm not sure that the whole thing couldn't be global -- that the assumption shouldn't be this stuff remains the same more often than not. | 17:15 |
| yvl | if 25% of them change, I'd rather keep 75% of them identical in the db | 17:15 |
| th1a | Again, CTE is an extreme case in this regard. | 17:15 |
| th1a | But, tbh, I don't want to stop and fiddle with it right now. | 17:15 |
| yvl | let's implement as is, and if it gets in the way too much we can still change our minds and quickly unfuck it this year | 17:16 |
| th1a | Yes. | 17:16 |
| yvl | ping? | 17:19 |
| th1a | OK, sorry. | 17:19 |
| replaceafill | i have a question for yvl | 17:19 |
| th1a | So... | 17:19 |
| replaceafill | yvl, David made an observation about the sorting of skillsets in the gradebook | 17:19 |
| replaceafill | usually, teachers see the skillsets sorted by skill "label" | 17:20 |
| replaceafill | i mean, what they call "local id" | 17:20 |
| replaceafill | the 001, 002, etc | 17:20 |
| aelkner_ | label in the model | 17:20 |
| replaceafill | right | 17:20 |
| aelkner_ | brb | 17:21 |
| yvl | now they should see them by the "order of creation" | 17:21 |
| replaceafill | the gradebook creates a worksheets property where i think sorting can take place | 17:22 |
| replaceafill | the gradebook should be the place for the sorting, right? | 17:23 |
| replaceafill | that shouldn't be in the model | 17:23 |
| th1a | Order is in the model. | 17:23 |
| th1a | (should be) | 17:23 |
| yvl | well, first - order is in the model, but I think I forgot "reordering" view for skillsets | 17:23 |
| replaceafill | th1a, what makes me wonder is David's comment on "can we allow teacher to sort alphabetically or by local id?" | 17:24 |
| replaceafill | yvl, ah | 17:24 |
| yvl | second, sectionskills have... order property inherited from Worksheet - so if you need per-section reordering, you can use it, and implement sorting in all_worksheets | 17:24 |
| th1a | We don't have to worry about that for a long time replaceafill. | 17:24 |
| replaceafill | yvl, ah | 17:25 |
| yvl | so there is a place to implement custom sorting, if that's what you're asking | 17:25 |
| replaceafill | yvl, so IWorksheets it the place | 17:25 |
| replaceafill | right | 17:25 |
| replaceafill | i just wanted to know what was it :D | 17:26 |
| replaceafill | thanks yvl | 17:26 |
| yvl | you're welcome :D | 17:26 |
| th1a | OK so I'm thinking under a year you have "Skills Documents" | 17:26 |
| th1a | And then the standard index view there. | 17:26 |
| aelkner_ | i'm back | 17:26 |
| th1a | You can add one there of course. | 17:26 |
| th1a | Then in the Skill Document you have to define the layers. | 17:27 |
| th1a | And then... | 17:27 |
| th1a | Essentially it has to let you work down through the hierarchy adding stuff . | 17:29 |
| th1a | The UI has to adapt to the layer titles. | 17:29 |
| yvl | yes | 17:30 |
| yvl | maybe then Skills (or something) appear in yearly view | 17:30 |
| th1a | And the fact that skillsets and skills are global has to be transparent. | 17:30 |
| yvl | true | 17:30 |
| yvl | when in node you should be able to both | 17:30 |
| yvl | - add a skillset | 17:31 |
| yvl | - assign existing skillset | 17:31 |
| th1a | Only if you're in the right layer of the hierarchy. | 17:31 |
| th1a | aelkner_: A lot of what is different about this task is just that we have to let the user call things whatever they want and use that in the interface. | 17:32 |
| th1a | Other than that the add node views don't need to be fancy. | 17:32 |
| yvl | (just to confirm - bottom layer is the right layer?) | 17:33 |
| th1a | We just have to remember that for this user they want the node to be called a "Cluster" so it has to say "Add: Cluster" not "Add: Node" | 17:33 |
| th1a | You can add a skillset if you're in the level above skillsets. | 17:34 |
| th1a | We're enforcing rules here that aren't required by the model. | 17:34 |
| th1a | Is this making sense aelkner_? | 17:36 |
| yvl | (umm, since one does not define skillsets, bottom layer becomes "layer above skillsets") | 17:36 |
| th1a | What do you mean one does not define skillsets? | 17:37 |
| yvl | does not define as a layer | 17:37 |
| yvl | they just... are | 17:37 |
| th1a | As far as the user is concerned he does. | 17:37 |
| yvl | ah, ok | 17:37 |
| th1a | Hiding the way it is modeled is our problem. | 17:37 |
| yvl | cool | 17:37 |
| aelkner_ | th1a, to answer your question to me, uh, no :( | 17:38 |
| th1a | OK, first wipe your brain of all preconceptions. | 17:38 |
| th1a | We're staring fresh here. | 17:38 |
| th1a | You're a teacher. | 17:38 |
| aelkner_ | what we need is a ui script | 17:38 |
| aelkner_ | one that is precise, that documents every click the user makes | 17:39 |
| aelkner_ | otherwise, it's just theoretical talk | 17:39 |
| th1a | You have never heard of the Commonwealth of Virginia and never imagined that a system of skills could be as screwed up as VA CTE's. | 17:39 |
| th1a | What you have, aelkner, is a document describing a three level hierarchy of skills. | 17:39 |
| th1a | Like ENGLISH - WRITING - PERSUASIVE ESSAY | 17:40 |
| th1a | ENGLISH - WRITING - NARRATIVE REPORT | 17:40 |
| th1a | MATH - ALGEBRA - FACTORING | 17:40 |
| th1a | The layers are SUBJECT - CLUSTER - STANDARD. | 17:40 |
| th1a | Your task is to enter this document into SchoolTool. | 17:41 |
| aelkner_ | so, as s user, where you do clck first? | 17:41 |
| th1a | As it turns out, this sort of simple hierarchy is the only kind of document you can enter through the web in SchoolTool. | 17:41 |
| aelkner_ | this is what i mean by a ui script | 17:41 |
| th1a | If you have a crazy fucked up mess you have to import it. | 17:41 |
| th1a | So you go to School and under the year you click Skills Documents | 17:42 |
| yvl | +1 | 17:42 |
| th1a | Then Add: Skills Document | 17:42 |
| aelkner_ | slow down | 17:42 |
| th1a | s | 17:42 |
| th1a | k | 17:42 |
| th1a | i | 17:42 |
| th1a | l | 17:42 |
| th1a | l | 17:42 |
| th1a | s | 17:42 |
| th1a | 17:42 | |
| th1a | d | 17:42 |
| th1a | o | 17:42 |
| th1a | c | 17:42 |
| aelkner_ | stop! | 17:42 |
| th1a | u | 17:42 |
| th1a | m | 17:42 |
| th1a | e | 17:42 |
| aelkner_ | you're not helping | 17:42 |
| th1a | n | 17:42 |
| th1a | t | 17:42 |
| th1a | :-D | 17:42 |
| aelkner_ | so the user goes to the year | 17:43 |
| aelkner_ | they click Skills Documents | 17:43 |
| aelkner_ | what do they see? | 17:43 |
| th1a | An empty index. | 17:43 |
| aelkner_ | and empty container view | 17:43 |
| aelkner_ | no documents added yet | 17:43 |
| aelkner_ | so there is an Add linkset with Skill Document | 17:43 |
| aelkner_ | they click on that, what do they see? | 17:44 |
| th1a | I'm thinking they see a form that lets them create the layers. | 17:44 |
| aelkner_ | i can't imagine such a form | 17:44 |
| th1a | Like one of your forms where you can add one line at a time. | 17:45 |
| aelkner_ | describe it for me please | 17:45 |
| th1a | Like score systems. | 17:45 |
| aelkner_ | hm | 17:45 |
| th1a | Our user above has to be able to enter "SUBJECT" | 17:45 |
| th1a | add a line | 17:45 |
| th1a | "CLUSTER" | 17:45 |
| th1a | add a line | 17:45 |
| th1a | "STANDARD" | 17:46 |
| th1a | hit DONE | 17:46 |
| yvl | +1 so far | 17:46 |
| th1a | (SUBMIT, whatever) | 17:46 |
| aelkner_ | how does that crete a heirarchy? | 17:47 |
| th1a | Then we have to parse that, make SUBJECT a layer, start calling skillsets CLUSTER and skills STANDARD. | 17:47 |
| th1a | (in this document) | 17:47 |
| th1a | Then you'll get a SUBJECT index view | 17:48 |
| aelkner_ | ok, maybe i'm not understanding how simpe layers may in fact be | 17:48 |
| aelkner_ | the root layer can only contain one layer | 17:48 |
| th1a | We're making them much simpler for TTW. | 17:48 |
| aelkner_ | and in turn, that layer can only caontain one layer | 17:48 |
| th1a | Otherwise nobody will ever be able to use this. | 17:48 |
| aelkner_ | so, we allow the user to create a list of layers | 17:49 |
| aelkner_ | and then, we use the order of the list to determine who contains who? | 17:49 |
| aelkner_ | im not talking model, ust ui | 17:49 |
| th1a | Yes. | 17:49 |
| aelkner_ | the thing is, yvl already created a layers view, just now | 17:51 |
| aelkner_ | are we saying we should scrap that? | 17:52 |
| yvl | I would say so, yes | 17:52 |
| aelkner_ | ah, i see | 17:52 |
| th1a | As I said a little while ago: | 17:52 |
| th1a | OK, first wipe your brain of all preconceptions. | 17:52 |
| th1a | We're staring fresh here. | 17:52 |
| th1a | What yvl did should help though. | 17:53 |
| aelkner_ | so, assuming that the Layes link on the School tab will go to the new view | 17:54 |
| aelkner_ | and that view has the form that allows the user to create a list of layes | 17:54 |
| aelkner_ | and that list will automatically be parent to child | 17:55 |
| aelkner_ | then we could have layers defined for the year | 17:55 |
| aelkner_ | what's next, then? | 17:55 |
| th1a | There will be no layers link. | 17:55 |
| th1a | That will all be completely hidden from the user. | 17:55 |
| aelkner_ | well, the form that we are discussing has to be accessible to the user | 17:56 |
| th1a | OK, so I've got SUBJECT - CLUSTER - STANDARD defined in my document. | 17:56 |
| aelkner_ | how does the user get to that form? | 17:56 |
| th1a | All they know is they have a document, and they just defined SUBJECT - CLUSTER - STANDARD. | 17:56 |
| th1a | They did Add: Skills Document | 17:57 |
| aelkner_ | from the year view? | 17:57 |
| th1a | And defined the structure of the document. | 17:57 |
| th1a | Now... | 17:57 |
| th1a | They'll basically have pretty standard index views. | 17:57 |
| th1a | SUBJECT index | 17:58 |
| th1a | Add SUBJECT | 17:58 |
| th1a | Create "English" | 17:58 |
| th1a | then from the English page Add: CLUSTER | 17:58 |
| th1a | Create "Writing" | 17:58 |
| th1a | From Writing Add: STANDARD | 17:59 |
| th1a | Create "Persuasive Essay" | 17:59 |
| th1a | Transparent to them, Writing is a skillset | 17:59 |
| th1a | and Persuasive Essay is a skill. | 17:59 |
| aelkner_ | now, of course, all of that assumes what your said above: | 18:00 |
| aelkner_ | so I've got SUBJECT - CLUSTER - STANDARD defined in my document | 18:00 |
| aelkner_ | my question was, how? | 18:00 |
| aelkner_ | i'm a user, i need to click something | 18:01 |
| aelkner_ | School tab, then Layers link? | 18:01 |
| th1a | Like one of your forms where you can add one line at a time. | 18:01 |
| th1a | <aelkner_> describe it for me please | 18:01 |
| th1a | <th1a> Like score systems. | 18:01 |
| th1a | <aelkner_> hm | 18:01 |
| th1a | <th1a> Our user above has to be able to enter "SUBJECT" | 18:01 |
| th1a | add a line | 18:01 |
| th1a | "CLUSTER" | 18:01 |
| th1a | add a line | 18:01 |
| th1a | "STANDARD" | 18:02 |
| th1a | hit DONE | 18:02 |
| th1a | (SUBMIT, whatever) | 18:02 |
| th1a | <aelkner_> so the user goes to the year | 18:02 |
| th1a | they click Skills Documents | 18:02 |
| th1a | what do they see? | 18:02 |
| th1a | <th1a> An empty index. | 18:02 |
| th1a | <aelkner_> and empty container view | 18:02 |
| th1a | no documents added yet | 18:02 |
| th1a | so there is an Add linkset with Skill Document | 18:02 |
| th1a | they click on that, what do they see? | 18:02 |
| th1a | <th1a> I'm thinking they see a form tha | 18:02 |
| aelkner_ | so Skills Documents link is added to year view, and that takes you to the layers form? | 18:03 |
| th1a | Yes, because that's always the first step. | 18:03 |
| aelkner_ | so Skills Documents is what the user will think of as what we call layers | 18:04 |
| yvl | yes | 18:04 |
| aelkner_ | th1a, btw, retyping what you said earlier in the chat doesn't help | 18:04 |
| aelkner_ | especially when it didn't make sense the first time | 18:04 |
| aelkner_ | for instance | 18:04 |
| aelkner_ | i can a contradiction from the chat here | 18:05 |
| th1a | The document is what the user is interested in. | 18:05 |
| aelkner_ | starting from the year view | 18:05 |
| aelkner_ | there is a Skills Documents links | 18:06 |
| aelkner_ | link | 18:06 |
| aelkner_ | there they find a form that lists layers | 18:06 |
| aelkner_ | and we automagically set parent to child, no | 18:06 |
| aelkner_ | np | 18:06 |
| th1a | ? | 18:06 |
| th1a | They'll get a form that explains that the first step in the process is defining the levels of hierarchy in their document. | 18:07 |
| th1a | Which will be fairly clear to them. | 18:07 |
| th1a | Since they'll have a document sitting in front of them arranged in a clear hierarchy. | 18:07 |
| aelkner_ | fine, so they can add layers | 18:08 |
| aelkner_ | that's all the form can allow | 18:08 |
| aelkner_ | it can't do two things at once | 18:08 |
| th1a | Well, it has to be a clever form. | 18:08 |
| th1a | It can't add the levels as you go. | 18:09 |
| aelkner_ | no? | 18:09 |
| th1a | It has to look at the whole structure and convert them to levels and note what it needs to call skillsets and skills. | 18:09 |
| th1a | The last level is not a level but a skillset. | 18:09 |
| yvl | th1a, can we drop that feature? | 18:10 |
| th1a | I'm not sure what that would mean. | 18:11 |
| aelkner_ | btw, a clever form is not what a user wants to see, a simple one is preferable | 18:11 |
| yvl | just make the last level and the a "skillset" | 18:11 |
| aelkner_ | breaking the task up into separate form is not a sin | 18:11 |
| th1a | The form is simple for the user, that's the point. It is just more complicated for the developer. | 18:11 |
| yvl | but think about it | 18:12 |
| yvl | if you "rename" the skillset in the UI | 18:12 |
| yvl | then that rename has to be stored somewhere | 18:12 |
| *** ignas has quit IRC | 18:12 | |
| yvl | and at the moment there's just no place to put that | 18:12 |
| yvl | then if user wants to do an import... | 18:12 |
| yvl | you want to have multiple names for skillsets? | 18:12 |
| yvl | I guess we could support that | 18:13 |
| aelkner_ | replaceafill, can you follow this? | 18:13 |
| th1a | It isn't such a big deal. | 18:13 |
| yvl | from the code's perspective... we could add an attribute to the layer called "skillset name" | 18:13 |
| yvl | from the *code's* perspective | 18:13 |
| replaceafill | aelkner_, i'm doing gradebook work, sorry | 18:14 |
| yvl | and if a "skillset name" is set, that's how we will call skillsets of nodes in that layer | 18:14 |
| yvl | doable | 18:14 |
| yvl | but extra work | 18:14 |
| yvl | th1a, can we ignore this feature, and add it this summer? | 18:14 |
| yvl | it will be somewhat faster to do without it, and it can be added "on top" nicely | 18:15 |
| yvl | it's just one of those situations "and we're gonna build the house... in a swamp - it's not a big deal" | 18:15 |
| * yvl is exaggerating | 18:16 | |
| yvl | what do you think, th1a ? | 18:16 |
| th1a | Well, I think we may have one part missing in the current model. | 18:16 |
| th1a | What is equivalent to the "Skills Document?" | 18:17 |
| yvl | well, layers | 18:17 |
| yvl | but there's a catch | 18:17 |
| yvl | the naming is flexible up to, but not including skills and skillsets | 18:18 |
| yvl | Subject - cluster - skillset | 18:18 |
| th1a | There has to be a document object. | 18:18 |
| yvl | the last one is always skillset | 18:18 |
| th1a | And one of its attributes could be skillset label (optional) | 18:18 |
| yvl | I do not understand you, sorry | 18:19 |
| yvl | there are two separate things : definition and data | 18:19 |
| th1a | There is essential metadata that has to be attached to a document object. | 18:19 |
| yvl | definition is layers | 18:19 |
| yvl | data is nodes | 18:19 |
| yvl | data is skillsets | 18:19 |
| yvl | data is skills | 18:20 |
| yvl | layers define dependencies between nodes | 18:20 |
| yvl | skillsets are not nodes | 18:20 |
| th1a | But all that has to be wrapped up in a document object. | 18:20 |
| yvl | the what now? | 18:20 |
| yvl | hmm | 18:21 |
| yvl | lemme think | 18:21 |
| th1a | In the end, that's what it is all about. | 18:21 |
| th1a | This is the standards defined by VA CTE in July of 2012. | 18:21 |
| yvl | ok, I think I know what you want | 18:21 |
| yvl | so the answer would be yes and no | 18:22 |
| yvl | skillsets will never be nodes | 18:22 |
| yvl | makes no sense for code | 18:22 |
| yvl | so | 18:22 |
| yvl | if you want that feature | 18:22 |
| th1a | I don't want them to be nodes. | 18:22 |
| th1a | The only thing I care about is that within the context of a document they won't be called skillsets. | 18:22 |
| yvl | ok | 18:23 |
| yvl | thanks for making this clear | 18:23 |
| yvl | doable, but extra work | 18:23 |
| yvl | I would suggest implementing this this summer | 18:23 |
| yvl | or now | 18:23 |
| yvl | layers basically need attribute skillset_title=None | 18:23 |
| th1a | Lets just do it now because the whole TTW UI won't make any sense otherwise. | 18:24 |
| yvl | it skillset_title is not None, that's how the skillsets should be called in UI | 18:24 |
| yvl | for nodes that are linked with this layer | 18:24 |
| th1a | Yes, that's fine. | 18:24 |
| yvl | for multi-layer nodes... I don't know | 18:24 |
| yvl | maybe there won't be a problem | 18:24 |
| yvl | nah, probably not | 18:24 |
| th1a | So I guess we will have to implement some kind of very simple document object. | 18:25 |
| yvl | what document object? | 18:25 |
| yvl | what are you talking about? | 18:25 |
| yvl | document object as UI metaphor | 18:25 |
| yvl | or as in document object in code | 18:26 |
| th1a | Well, I guess currently it is just a top level layer? | 18:26 |
| yvl | what? | 18:26 |
| yvl | no | 18:26 |
| th1a | Just another layer? | 18:26 |
| yvl | look | 18:26 |
| yvl | I don't understand what you want with the document object, but | 18:27 |
| yvl | I think I understand what functionality you want in the end | 18:27 |
| yvl | so, no object | 18:27 |
| yvl | just a line called skillset_title in the code in the bottom layer | 18:28 |
| th1a | What document a skill is derived from is vitally important to this entire task. | 18:28 |
| yvl | ah! | 18:28 |
| yvl | now I remember | 18:28 |
| th1a | This skill is from CTE Skills 2012. | 18:29 |
| yvl | then yes - a top layer | 18:29 |
| th1a | This one is from Common Core Math. | 18:29 |
| yvl | a top layer, called "Document Model" | 18:29 |
| yvl | and a node "Common Core Math" for layer "Document Model" | 18:30 |
| th1a | It isn't so much the document model as the document. | 18:30 |
| yvl | and a node "CTE Skills 2012" for layer "Document Model" | 18:30 |
| th1a | So when I do Add: Skills Document, what should be created? | 18:31 |
| yvl | oh that is a good question | 18:32 |
| th1a | Ah! | 18:32 |
| yvl | ok, this is not implemented | 18:33 |
| yvl | you could implement it like this: | 18:34 |
| yvl | when you click add skills document | 18:34 |
| yvl | a layer is created | 18:34 |
| yvl | all layers with no parents are considered skill documents | 18:35 |
| yvl | (should be) | 18:35 |
| yvl | tada! | 18:35 |
| yvl | ok, so yes, just another layer | 18:35 |
| yvl | sorry, it's getting late here, brain malfunctions increase | 18:35 |
| th1a | np. | 18:36 |
| aelkner_ | i agree that the model doesn't need to change | 18:36 |
| aelkner_ | it | 18:36 |
| aelkner_ | it's just the ui that needs defintion | 18:36 |
| th1a | In the model does each level know what is supposed to be above and below? | 18:36 |
| aelkner_ | if a layer has no parent, as yvl said, then it is at the root level | 18:37 |
| yvl | it knows it's direct parents and direct children | 18:37 |
| yvl | so yes | 18:37 |
| th1a | OK. | 18:37 |
| th1a | What if it has no children. I guess it just knows that. | 18:38 |
| yvl | yes | 18:38 |
| yvl | if it has no children, it is in bottom | 18:39 |
| yvl | at it should have skillset_title set | 18:39 |
| aelkner_ | ok, that's the part that makes no sense to me | 18:39 |
| aelkner_ | layers are not skillsets | 18:39 |
| yvl | true | 18:40 |
| yvl | but th1a wants | 18:40 |
| yvl | to specify | 18:40 |
| yvl | that if a node is created in layer "STANDARD" | 18:40 |
| yvl | when you assign skillsets to it | 18:40 |
| yvl | whoops, sorry | 18:41 |
| yvl | if a node is created in layer "CLUSTER" | 18:41 |
| yvl | skillsets assigned to that node should be called "STANDARD" everywhere in UI | 18:41 |
| yvl | when user creates document model, he enters | 18:41 |
| yvl | "th1a's Document Model" - "SUBJECT" - "CLUSTER" - "STANDARD" | 18:42 |
| yvl | layers "th1a's Document Model" - "SUBJECT" - "CLUSTER" are created | 18:42 |
| th1a | Cluster would be the skillset | 18:43 |
| aelkner_ | no | 18:43 |
| aelkner_ | layers are not skillsets | 18:43 |
| yvl | true | 18:43 |
| yvl | but hear me out, aelkner_ | 18:43 |
| yvl | we don't create the last two lines as layers | 18:43 |
| yvl | only "th1a's Document Model" and -> "SUBJECT" layers, as th1a points out | 18:44 |
| yvl | and then, in subject layer we set two new attributes | 18:44 |
| yvl | skillset_title="CLUSTER" and skill_title="STANDARD" | 18:44 |
| yvl | and then in UI, instead of writing "Assign Skillset", we write "Assign CLUSTER" | 18:45 |
| yvl | and instead of "Skills" we add "STANDARD" | 18:45 |
| yvl | umm /s/add/use | 18:45 |
| yvl | it's kind of crazy, I know | 18:46 |
| yvl | so the most minimal possible document model is: | 18:46 |
| yvl | "document model title" - "skillset title" - "skill title" | 18:47 |
| yvl | it will be only one layer, "document model title" | 18:47 |
| yvl | very lonely, no parents, no children | 18:47 |
| yvl | does that make some sense? th1a? aelkner_? | 18:48 |
| aelkner_ | sorry, not really | 18:48 |
| th1a | Perhaps we should let yvl go and aelkner_ and I can continue to hash this out. | 18:48 |
| yvl | ok | 18:48 |
| yvl | I'll just sum it up for reference :) | 18:48 |
| yvl | in add document model view | 18:49 |
| yvl | user enters lines, 3 lines minimum | 18:49 |
| yvl | layers are created for lines[0..len(lines)-3] | 18:49 |
| yvl | layer [len(lines)-3].skillset_title = lines[-2] | 18:50 |
| yvl | layer [len(lines)-3].skill_title = lines[-1] | 18:50 |
| yvl | if layer.skillset_title is not None: | 18:50 |
| yvl | sorry | 18:50 |
| yvl | if node.layers[0].skillset_title is not None: | 18:51 |
| aelkner_ | layersdon't have sillset_title attribute | 18:51 |
| yvl | skillsets can be added | 18:51 |
| yvl | yes aelkner_ | 18:51 |
| yvl | you will have to add those | 18:51 |
| yvl | (just simple text lines) | 18:51 |
| yvl | or I can do that tomorrow morning, after reading today's IRC log | 18:51 |
| yvl | ok, thanks guys! | 18:52 |
| th1a | Let's take a 15 minute break aelkner_. | 18:53 |
| aelkner_ | ok | 18:53 |
| *** yvl has quit IRC | 18:59 | |
| th1a | ready aelkner_? | 19:09 |
| aelkner_ | ready | 19:12 |
| th1a | OK, so here is where we are. | 19:13 |
| th1a | We've got the basic data model implemented and can import levels, skills and nodes in such a way that they are usable in the gradebook. | 19:14 |
| th1a | But a few things are missing to make these abstractions usable. | 19:14 |
| th1a | (usable in terms of understanding and managing the standards through the web) | 19:15 |
| th1a | So some things need to be added, changed, and/or hidden. | 19:15 |
| th1a | I think one problem here is that VA CTE skills is an insane soup. | 19:16 |
| th1a | Generally, we're just dealing with a simple hierarchy. | 19:16 |
| th1a | So we're trying to pull these together. | 19:17 |
| aelkner_ | i'm not thinking that VA CTE is such an insane soup, really | 19:18 |
| th1a | To be honest, we may need two separate ttw systems. | 19:18 |
| aelkner_ | it just has two different heirachies | 19:18 |
| aelkner_ | which we could consider two documents using the terms you started using today | 19:19 |
| aelkner_ | and we can deal with one at a time | 19:19 |
| *** mattva01 has quit IRC | 19:19 | |
| aelkner_ | but, the thing is, yvl went through the troble of having layers and nodes for a reason | 19:19 |
| aelkner_ | the user want to define sets of skills once and point to them twice | 19:20 |
| aelkner_ | and even if we do this simple form you are talking about | 19:20 |
| aelkner_ | we still have the model set up the way it is for a reason | 19:20 |
| aelkner_ | so, can we start by saying that a heirachy, the first one we create with our form | 19:20 |
| aelkner_ | is one document model, a root layer, i.e., having no parent | 19:21 |
| aelkner_ | but having one child, which in turn has one child | 19:21 |
| aelkner_ | these are only layers, but they allow the user to define the document | 19:22 |
| th1a | Perhaps the first thing we should do is just make a skills browser without worrying about add/edit. | 19:22 |
| aelkner_ | hm, good idea | 19:22 |
| th1a | Or... can we do that now. | 19:22 |
| aelkner_ | we already have import,so... | 19:22 |
| th1a | Can you see them? | 19:22 |
| aelkner_ | i prefer you new idea | 19:22 |
| aelkner_ | see them? | 19:22 |
| aelkner_ | we can now see the layers | 19:23 |
| aelkner_ | go to School tab, click layers | 19:23 |
| aelkner_ | Layers | 19:23 |
| th1a | replaceafill: Can we import some skills into this instance? | 19:23 |
| aelkner_ | it's crude, a not i know it's not what we want for the user, but it is a start | 19:23 |
| aelkner_ | i can import them | 19:23 |
| replaceafill | th1a, sure | 19:24 |
| aelkner_ | can you chat the link again please? | 19:24 |
| replaceafill | http://69.164.203.135:6665 | 19:24 |
| aelkner_ | ah, i see you entered a skillset ttw | 19:25 |
| aelkner_ | th1a, data imported | 19:27 |
| aelkner_ | you'll note that now there are two skillsets | 19:27 |
| aelkner_ | the one replaceafill added manually, and the imported on | 19:28 |
| aelkner_ | the layers can be viewed ttw, but the nodes can't yet | 19:28 |
| replaceafill | i think th1a added it :) | 19:28 |
| aelkner_ | and the nodes are the ones that have linkage to the skillsets | 19:28 |
| aelkner_ | anyway, that is what we have to start | 19:28 |
| th1a | OK, so we have everything in here and viewable, just not in a way that makes any sense. | 19:29 |
| aelkner_ | not all viewable, nodes missing, but otherwise, yes | 19:29 |
| th1a | Nodes are missing? | 19:31 |
| aelkner_ | the data exists, there's just no view to see it | 19:31 |
| th1a | OK, maybe you should start with that. | 19:32 |
| aelkner_ | if you'd like | 19:32 |
| aelkner_ | i could add a Nodes link under the Layers link in the School tab | 19:33 |
| aelkner_ | it would take you to the same exact kind of container view that Layers does | 19:33 |
| th1a | tbh it doesn't really need a link at all since it won't be staying there. | 19:33 |
| aelkner_ | the container would be the NodesContainer, and the Add link would be Node | 19:33 |
| th1a | Put the link where-ever you want for now. | 19:34 |
| aelkner_ | it's easier to have the link then have to keep mousing over to the url to edit it | 19:34 |
| th1a | Whatever is easiest. | 19:35 |
| aelkner_ | but anyway, it would be a reasonable task to create the same kind of view for Nodes | 19:35 |
| aelkner_ | that yvl created for Layers | 19:35 |
| aelkner_ | and that would also allow me to add automated tests for the importer | 19:36 |
| aelkner_ | until now, we only have them for skillsets and skills | 19:36 |
| aelkner_ | even if we move the Layers and Nodes links, it won't be hard to fix the tests to navigate differently | 19:36 |
| th1a | Uh... I wouldn't go nuts with tests yet. | 19:37 |
| aelkner_ | i'm just thinking that we could retain these views no matter what more clevel forms we make later | 19:37 |
| th1a | ok | 19:38 |
| aelkner_ | but, yes, i can wait on writing those tests for when i'm blocked some other way | 19:38 |
| aelkner_ | so, ok, I will make the Nodes views modeled after the Layers views | 19:38 |
| th1a | Well, do you think you can have those views for tomorrow? | 19:38 |
| aelkner_ | that seems a little soon | 19:39 |
| aelkner_ | otherwise, yvl would have had it done already | 19:39 |
| aelkner_ | but, like i said, it is a reasonable task | 19:40 |
| th1a | OK, well just start working on that and we'll check in tomorrow afternoon. | 19:40 |
| aelkner_ | ok | 19:40 |
| th1a | (or sooner as necessary) | 19:40 |
| aelkner_ | well, i would say that we can discuss the other form any time you want | 19:41 |
| aelkner_ | and that can be independent of getting the Nodes, let's call it "raw" view working | 19:41 |
| th1a | Once we get this piece done it may be more clear how they fit together. | 19:42 |
| aelkner_ | ok, we'll see | 19:42 |
| aelkner_ | shall we meet at 2:00 tomorrow? | 19:43 |
| th1a | Sure. | 19:44 |
| replaceafill | th1a, can i have your opinion on a little change to the worksheets list: | 19:54 |
| replaceafill | http://69.164.203.135:6660/schoolyears/2011-2012/2012-spring/sections/math_a_2012-spring_teacher001_000/projects/Project-2/gradebook | 19:54 |
| replaceafill | click on the arrow pointing down :) | 19:54 |
| replaceafill | i inverted the color of the menu | 19:55 |
| replaceafill | to mark the active sheet | 19:55 |
| replaceafill | does that look ok? | 19:55 |
| replaceafill | brb | 20:07 |
| *** menesis has quit IRC | 20:18 | |
| *** menesis has joined #schooltool | 20:19 | |
| *** paulproteus has quit IRC | 20:22 | |
| *** paulproteus has joined #schooltool | 20:24 | |
| *** menesis has quit IRC | 20:24 | |
| th1a | Yes. | 20:28 |
| th1a | replaceafill, . | 20:28 |
| th1a | Looks good. | 20:28 |
| *** ignas has joined #schooltool | 21:03 | |
| *** menesis has joined #schooltool | 21:10 | |
| * replaceafill back | 21:11 | |
| *** th1a has quit IRC | 22:48 | |
| *** th1a has joined #schooltool | 23:17 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!