Ken Zolot spoke on entrepreneurialsm in orgs. Good lessons for coupling execution with innovation.
Learning 2011 Interview Mindmaps
Koulopoulos Keynote Mindmap
Michio Kaku Keynote Mindmap
Sage at the Side
A number of years ago, I wrote an article (PDF) talking about how we might go beyond our current ‘apart’ learning experiences. The notion is what I call ‘layered learning’, where we don’t send you away from your life to go attend a learning event, but instead layer it around the events in your life. This is very much part of what I’ve been calling slow learning, and a recent conversation has catalyzed and crystalized that thought.
Think about the sort of ideal learning experience you might have. As you traverse the ‘rocky road’ of life, imagine having a personal coach who would observe the situation, understand the context of the task and the desired goal, and could provide some aid (from some sack of resources) that could assist you in immediate performance. Your performance would improve.
Let’s go further. This sage, moreover, could draw from some curricula (learning trajectories) and prepare you beforehand and guide reflection afterward so that real performance event now becomes a learning opportunity as well, helping you understand why this particular approach makes sense, how to adapt it, and more. In this way, the sage moves from performance coach to learning mentor.
One step further would be to have learning trajectories not only about the domain (e.g. engineering) but also about quality, management, learning, and more. So learners could be developed as learners, and as persons, not just as performers.
Now this would be ideal, but individual mentors don’t scale very well. But here’s the twist: we can build this. We can have curricula, learning objects, and build a sage via rules that can do this. Imagine going through your workday with a device (e.g. an app phone or a small tablet) that knows what you’re doing (from your calendar), which triggers content to be served up before, during, and after tasks, that develops you over time. We can build the tutor, develop and access the curricula and content, deliver it, track it.
I hope this is clear. There are other ways to think about this, and I’ll see if I can’t capture them in some way; stay tuned. The limitations are no longer the technology, the limits are between our ears. Reckon?
Don’t be Complacent and Content
Yesterday I attend SDL’s DITAFest. While it’s a vendor-driven show, there were several valuable presentations and information to help get clearer about designing content. And we do need to start looking at the possibilities on tap. Beyond deeper instructional design (tapping into both emotion and effective instruction, not the folk tales we tell about what good design is), we need to start looking at content models and content architecture.
Let me put this a bit in context. When I talk about the Performance Ecosystem, I’m talking about a number of things: improved instructional design, performance support, social learning and mobile. But the “greater integration” step is one that both yields immediate benefits, and sets the stage for some future opportunities. Here we’re talking investing in the underlying infrastructure to leverage the possibilities of analytics, semantics and more, and content architecture is a part of that.
So DITA is Darwin Information Typing Architecture, and what it is about is structuring content a bit. It’s an XML-based approach developed at IBM that lets you not only separate out content from how it’s expressed, but lets you add some semantics on top of it. This has been mostly used for material like product descriptions, such as technical writers produce, but it can be used for white papers, marketing communications, and any other information. Like eLearning. However, the elearning use is still idiosyncratic; one of the top DITA strategy consultants told me that the Learning and Training committee’s contribution has not yet been sufficient.
The important point, however, is that articulating content has real benefits. A panel of implementers mentioned reducing tool costs, reduced redundancy savings, and decreasing time to create and maintain information. There were also strategic benefits in breaking down silos and finding common ground with other groups in the organization. The opportunity to wrap quality standards around the content adds another opportunity for benefits. Server storage was another benefit. As learning groups start taking responsibility for performance support and other areas, these opportunities will be important.
And, the initial investment to start focusing on content more technically is a step along the path to start moving from web 2.0 to web 3.0; custom content generation for the learner or performer. A further step is context-sensitive customization. This is really only possible in a scalable way if you get your arms around paying tighter attention to defining content: tagging, mapping, and more.
It may seem scary, but the first steps aren’t that difficult, and it’s an investment in efficiencies initially, and into a whole new realm of capability going forward. It may not be for you tomorrow, but you have to have it on your radar.
Thinking Strategy, Pt. 2
Building on yesterday’s post, in another way of thinking about it, I’ve been trying to tap into several layers down. Like the caveat on an attempt at mind-mapping the performance ecosystem, this only begins to scratch the surface as each of these elements unpacks further, but it’s an attempt.
The plan you take (your sequence of prioritized goals), the metrics you use, and your schedule, will be individual. However, the other elements will share some characteristics.
Your governance plan should include a schedule of when the group meets, what policies guide the role of governance, what metrics the governance group uses to look at the performance of the group implementing the plan (ie how the executors of the strategy are doing, not how the strategy is doing), and what partners are included.
The strategy will need partners including fundamental ones providing necessary components (e.g. the IT group), and members who may have political reasons to be included such as power, budget, or related interests.
The resources needed will include the people, the tools, and any infrastructure elements to be counted upon.
Support capability will include supporting the team with any questions they might need answer, and also the folks for whom the strategy is for.
And there will need to be policies around what responsibility there will be for support, access to resources, and other issues that will guide how the strategy is put in place, accounting for issues like security and risk.
I’m sure I’m forgetting something, so what am I missing?
Thinking Strategy, Pt.1
I’ve been involved in a lot of strategic thinking lately, both for clients and workshops (e.g. my mobile strategy workshop at DevLearn next week), and so it’s forced me to reflect on what strategy is.
I’ve previously talked about the technology components of an elearning strategy, and how they tie together, but I need to take another cut at it. Naturally, I’ve been diagramming as my way to get my mind around strategy as a set of conceptual components that are necessary to identify and get right, regardless of domain.
A strategy has to start with a vision of what you’re trying to achieve. From there, you need to break it down into goals that, together would achieve this outcome.
Multiple things go along with this: the tactics that achieve the goals, the metrics that you use to measure your progress and success, the partners you need to work with, the resources you’ll need, the continual development of capability of the resources, and the messaging you’ll use to get others to buy in and assist.
It goes further, of course. Stay tuned for tomorrow.
Book Review Pointer
In case you didn’t see it, eLearn Mag has posted my book review of Mark Warschauer’s insightful book, Learning in the Cloud. To quote myself:
This is … a well-presented, concise, and documented presentation of just what is needed to make a working classroom, and how technology helps.
As one more teaser, let me provide the closing paragraph:
The ultimate message, however, is that this book is important, even crucial reading. This is a book that every player with a stake in the game needs to read: teachers, administrators, parents, and politicians. And not to put too delicate a point on it, this is what I think should be our next “man in the moon” project; implementing these ideas comprehensively, as a nation. He’s given us the vision, now it is up to us to execute.
I most strongly urge you, if you care about schooling, to read the book, and then promote the message.
Intimacy & Immediacy
I’ve been wrestling with the difference between the smartphone (or PDA, aka the ‘pod’) versus a tablet (aka the ‘pad’), and it occurred to me that one way to think about it might be to distinguish between ‘intimacy’ and ‘immediacy’.
By immediacy, I’m talking about how you use the devices. As Palm documented a long time ago, you use laptops only a few times per day, but for long periods of time. Whereas you use mobile devices many times a day for quick access. Tablets are actually more used like laptops in this respect. You don’t tend to whip your tablet out, answer a quick question, and put it away. The size tends to make it awkward to whip in and out, and instead is more amenable to using for a period of time. Of course, smaller tablets may bridge the gap.
By intimacy, I mean the relationship to the device. As Judy Brown defines a mobile device, it’s small enough to fit in your pocket, has a battery to last all day, and you really know it. I’m particularly picking up on the latter, and moreover, that you can customize it. David Pogue has opined that it’s not really the smartphone that matters, but rather the ‘app phone’, and I think it’s important that you can optimize the device by loading it with capabilities that accessorize your brain. Though you can add ringtones, and even some apps (via, for instance, Brew), it’s much harder to augment your capabilities without a rich market of differentiated programs.
There’s more. For one, the smaller screen means you have the device closer. Laptops are inherently at arms length (or at least forearm’s length), to effectively use a keyboard. The smaller screen of a mobile device invites it closer, as does the small keyboard, using thumbs instead of the whole hand. A touchscreen interface also invites a different relationship.
This gives me a framework for distinguishing between the devices. A laptop, even if customized by your applications, isn’t intimate, and by size isn’t used with immediacy. Tablets are intimate, but not immediate. Smartphones are intimate and immediate. Finally, there’s the category of immediate but not intimate. This might be the use of a touchscreen kiosk you find at a public spot or in a museum, or perhaps also using someone else’s device for a quick access.
This seems to give me a handle on thinking about the differences between tablets and smartphones & PDAs (I think the iPod touch is a great device, say for kids in schools). Does it work for you?