mtd> It strikes me that Eben's bulletin board designs just mentioned on IAEP seem to involve sharing things, and patches are things, and perhaps this is the answer to my patch-sharing itch. I should probably just spawn a tangent thread on the mailing list. m_stone> well, I found eben's answer quite non-satisfactory, first, because I think that bulletin boards are quite different from activities and second, because he didn't give any sense of _order_. narratives are _sequences_ of events. (and narratives which _will_ take place, with user input, are often tree or DAG-structured.) they are not simply sets of events.
bemasc> I suggest a concrete example. I think neither I nor Eben has comprehended your concept of narrative correctly. m_stone> think of literary narratives. the point is that they have order. for example, the narrative-as-graph is like a choose-your-own-adventure book. [and yes, I'm actually thinking of hypertext and RPG dialogue code here...] mtd> narrative-as-equence? I understand the analogy but think that literary criticism has much to say about linear, one-way communication as "storytelling". I am going to have to cite the xkcd about literary criticism if I don't. There, I did. And I like your RPG-style thinking. But now I'll really stop, as, a bit like bemasc, I know nothing about education or psych.
m_stone> did you understand walter's reply? bemasc> this discussion is not oriented in a way that works well for me. I think of Sugar as ... a virtual machine for untrusted code. I don't know anything about education or psychology, and I have little interest in speculating about either. m_stone> look, you've both undergone lots of education, same as me. we're all on equal footing here. I'm just pointing out the simple fact that a fairly large chunk of the education you underwent consisted of discrete experiences embedded in rhetoric. (http://en.wikipedia.org/wiki/Rhetorical_modes) mtd> rhetoric++. Ther'es a lot to be said for a clear, precise, compact explanation. Sometimes you need the answer to help you think about what you thought the answer was.
m_stone> Bryan's remarks about the amount of effort and frustration stemming from the increased demand for lesson plans suggested to me that Sugar was making it hard for teachers to string together the experiences they wanted to share with their classes and their peers. Bryan's desire for Offline-Moodle clearly stems from the fact that he thinks that hypertext (and Moodle, which generates hypertext) is pretty good for stringing together experiences and he thinks that it's within his budget. mtd> ah, and lesson-plan-asnarrative-sequence, I get it. the best perormance improvement is going from a non-working stateto a working state. I suspect "sugar making it hard" was "sugar making it possible in a different way than just writing on a blackboard" in some cases.
bemasc> ok, lesson plans. that's something I know how to think about. I still don't really get it though. I don't see a big gulf between a teacher saying "now take out a paper and write a six-stanza poem with the rhyme scheme we just discussed" (an actual assignment from 11th grade or so) and "now open up Write and ..." m_stone> suppose you want the kids to work on it at home... it's true that one solution is to provide a write document containing instructions, but, imho, that's not a very good solution for a couple of reasons. in particular, because it seems to completely constrain you to working in Write. (or to giving instructions on how to flip between write and other stuff when needed)
m_stone> another example I have in my head involves pippy examples. suppose I write up an awesome new Python trick and I want to explain it to you. I want my explanation to show you a buildup to the trick, a working example, and a collection of links to other tricks and tutorials. also, I want to prepare my explanation ahead of time, transfer it to you, and let you experience it without talking to you. how do I do that? mtd> 1) write is much less limiting than pre-printed paper with instructions and a blank space on the back for writing the poem; and 2) literate programming gets you a long way. m_stone> well, one common technique used in many good CS textbooks is to write a series of examples which build up to the ultimate example. and people who do multimedia projects commonly say 'go make your collage over here, then glue it into place on the worksheet...' bemasc> so you're creating a category that includes textbooks and recorded lectures.
m_stone> so what I think I'd want to try here would be a system that let me string together resumable activity instances and 'holes' for new instances to be put in. (maybe other things too later on, but those are the essential pieces. cscott tells me this is nothing more than ODF... however, I think that the UI is the important part). then I can just give you my explanation and you can pick whichever piece of it you like, resume it, and play with it.similarly, if there's something I want you to do with it (that you're going to give back to me), then I'll have made space for you. for example, maybe I want you to solve a puzzle or to take some photos. so maybe I put a blank record instance there for you? bemasc> why not just say "Now open Record"; "Now take some pictures with Record"? my textbooks are not interactive, and I managed to make it this far? They say "now solve the following problem" and so I take out my computer and write a program to solve the problem m_stone> I just think it's a better experience if you directly present people with the structure of what you want them to experience. it's like the difference between going on a hiking trip on a well-established trail vs. in the back-country... you can study the landscape from both, but the former is much more accessible. it requires less unnecessary decisionmaking, comprehension, and judgement. bemasc> I should say, I don't think what you describe is a bad idea, but it seems of minimal actual utility. I've seen many tutorials for various computer things that contain a picture of the icon that the author wants you to click
m_stone> does your opinion change if the people you're teaching can't read? bemasc> no, except that for people who can't read, none of this will work mtd> I think people are going to have to read to get lots of benefits out of narrative.
m_stone> put differently -- why are screencasts a valuable instructional tool when almost all screencasts arise from written instructions? bemasc> I don't know; I've never used a screencast mtd> s/read/use language/ m_stone> as the study of semiotics demonstrates, that difference matters. I'm inquiring about the utility of a fairly small visual language for 'here are a collection of things you should try doing'. (probably in some fairly specific order) mtd> hmm. I don't disagree there could be power in that, but I think the difficulty of creating even a small symbolic language that presupposes no existing symbolic language should not be underestimated.
bemasc> if you're simply proposing a way to allow one Activity to expose a widget that launches another activity, then I have nothing to argue about. I think that's a fine idea. I just don't think it represents a major leap in functionality, or enables any new behaviors that weren't easy already. it removes a single step of "find this icon on the home view" and removes zero clicks. mtd> I think the lesson plan UI is just going to help teachers build (or just perceive) more easily the plans for using the XO in the classroom. Fostering that perception is quite useful. I think it's actually a big leap in usability - it's moved the number of switches away from the activities involved to zero. From one per activity involved. To a computer user it's of course a "chasm" we've all crossed long ago. but perhaps not for first-time users (obviously I'm not able to imagine that situation myself, and I am unfamiliar with reasearch in that area, so i'm pulling this out of my ass) bemasc> for users who are truly uncomfortable with the interface, I see how having to switch to the home view and launch an instance could be a barrier
m_stone> it also avoids the need to invoke object choosers everywhere (P_DOCUMENT). if you have several activities linked together inside a single narrative container, then they can all interact happily w/out crossing any security boundaries. mtd> yes, for pre-existing documents...actually that's a lot of clicks you've done away with. I have noticed - completely anecdotally - the high cognitive load non-developers seem to experience keeping track of open / planned-to-open applications. (whereas I think most developers run several WMs on the wetware)
nteon> where in the current interface do you invision "now take some pictures with record" fit in? from your original email I had been thinking more about allowing kids to pull activities they had done into narratives, but I think that could fold into this broader concept you're talking about, although it is still somewhat nebulous to me. also, how would you link them together in the first place, through the journal? m_stone> I'm not sure yet. mtd> I did indeed think you were distributing an activity that allowed launching existing (and potential) instances of activities together. m_stone> that's one potential implementation but I don't have strong feelings about either the implementation or the graphics; instead, I'm thinking about the interaction design -- screens, input, waits, and so on mtd> the UI is definitely the innovation/interesting thing here m_stone> my other concern is how it should be displayed in the journal.
 Cost/Benefit Ratio
mtd> as bemasc and others have pointedout, the workflow/usage pattern is poosible now m_stone> 'possible' != 'efficient, smooth, polished, pleasant, ...'
m_stone> my current complaint about the journal is that the journal doesn't have any way of showing you things you _might_ do in the future. (or that someone wants you to do) nteon> I think it would really help the list thread to get your ideas down digitially, even if it is scanned in scribbles (like cscott's journal). I myself am having a hard time imaging things other than ebens bullitin board or a ppt style tool
bemasc> what you're describing sound to me like EPGY and other "distance learning" programs. more specifically, I would call this a "self- guided interactive lesson" m_stone> okay.... how does that conceptualization affect your judgement of its relevancy to encoding educational experiences for consumption by or through XOs? bemasc> I think this is very valuable but I maintain that it's already very much possible and that the technical barriers are negligible compared to the social barriers of finding people to write and translate these lessons. An HTML content bundle is better than close enough for me. m_stone> do you also assert that it's any of 'efficient, smooth, polished, pleasant, ...' ? also, how do I make one of those on an XO?
nteon> what about students wishing to string together a thread of activities telling a story of their experiences or of something they've learned? bemasc> they should write up a lesson. certainly if it's not easy to create content bundles on an XO... well, it should be. m_stone> (there are other problems with content bundles too, such as the copying-into-journal problem, the invisibility-of-bundle-in-journal problem, the what-the-hell-does-Bitfrost-say-about-these? problem, ...) but I take your point. as for the 'well, it should be'.... I'll reply: 'well, it certainly isn't yet, and no one is working on the problem either'. this is, in some sense, is the cause of my email -- I think that more people would work on this use case if the sugar vision said that this use case was important.
m_stone> in conclusion, what I'm saying is that it is currently all but impossible to write and share slick lessons on an XO, or to keep track of one's progress through a curriculum of lessons in the journal. bemasc> making content bundles work better sounds very valuable. We certainly don't provide nice content creation tools. I heartily agree that this is an area in which improvements are worth pursuing. m_stone> lovely. now if only you weren't in engaged in pursuit of further education... :) bemasc> right.