Work Journal for March 19th, 2014
It's hard to keep working when your laptop can't manage to type a single sentence without hanging for minutes on end.
On my bad days (which have been increasingly often given stress, fatigue, and disinterest), I can barely manage to write more than a sentence at a time myself. When I want to work, and can't because my system is acting up, it's very frustrating. Worse, I cannot transfer the documents to any other system I have because they require such a specifically licensed toolkit that there's nothing else I can do. So instead I sit here being unproductive.
The most infuriating part is that the system would occasionally be useful enough for me to get some bit of work done, only for it to stall at some random point and take away all of my momentum. It burns stress points just to do anything with the system in that state. And because the nature of the work is so specific, I can't even write elsewhere and finalize it when the system is functional again.
At least I think I've made some progress with the first module. I felt like I was stuck for the longest time because of the way I decided to spread the introduction of concepts throughout the entire class. Compared to simply teaching by feature, this feels like trying to write with one hand tied behind my back and jumping on one foot. It's extraordinarily difficult and makes things very hard to progress. It's difficult enough trying to deal with that given a stable system and no family or financial distractions.
The problem was workflows. Originally, I decided to include a brief section on workflows in module one without discussing what they are made of or how. That information was supposed to come in module 2 when I started to talk about the Development Studio in detail. I don't know what possessed me to think I could work like that without it being difficult. Usually I like introducing each piece as I come across it. Step over, then step in. The problem is that's a purely feature based approach. Everything at the CL Summit last January suggested that we need to get away from that mode of education. The problem is we never defined what we're doing instead.
From what I've worked on, basing a class's organization around business goals is generally a good strategy. Often this needs to be modified for IT education as rarely are students the sort that care about abstract business goals. Managers care about that. CEOs care about that. On the floor IT people care about making their job easier or their results better. "How does this help me do what I need to do better? How does it enable me to do more? How does it save me time?" These are concerns for IT people. This is why I hate calling them "business goals".
At first I thought putting all my material in the spreadsheet and doing a time estimate was going to be a big help. As I work on the class, however, it just seems like a waste of time. The organization did resolve some early issues, but I don't think doing everything in the spreadsheet was as helpful as it could have been. I usually like to find the story in the class I'm writing as I'm writing it. The problem is that this often results in feature-centric teaching even if it's sensibly organized for hands-on types. I understand why we want to move away from this mode. Teach-by-feature can easily be accomplished by any never of blog entries and careful internet searches. Online manuals teach features well. IT Education needs to do more.
I like goal-oriented teaching. If it were to be diagrammed, you'd write the goal in the middle. Then you surround the goal with the tasks you need to do to meet that goal. Then you design activities that work the student to those tasks. It's still a very new way of writing training material for me. I'm still not used to it. It's difficult to know what the goal needs to be when one has never used the product in a real environment. As such, my training material comes from a lot of research and educated guesses about how you use the product. Sometimes that's easy to do (like for cloud), and sometimes I have a difficult time even convincing myself the product is worth it (like orchestrator).
I thought I broke down the business goals well when orchestrator, but now I'm not so sure. When I did the spreadsheet earlier, I ended up with five goals: Orchestrate complex tasks, Include user interaction, monitor and remediate, and preform ETL tasks. This feels more feature centric the more I work with it. None of those are really goals that concern the product's target audience. The goals are valid, but very generic so as to be pointless. Something with more specific application would be helpful.
This class also has to be put in a broader context as well. This is the first web-based class in a curriculum of three classes total. The next two are instructor-led classes that teach features (figures) and then integrations with third party products. The main point of this first WBT was just to teach the "boring stuff" that the instructors would rather not bother with in person. This usually includes the grid architecture, the clients, components, etc.. That could imply that the web based class can be very short, covering only a minimum of material before handing it off to the instructor. In that case, however, why have a web based class at all? The web based class has to justify it's existence and provide sufficient value to be worth the purchase price.
This is where my thoughts become muddy enough I'm unsure how to continue.
