#6: Blondes and Wish Lists

11 thoughts on “#6: Blondes and Wish Lists”

1. Pingback: The ToolBar, Episode 6 – Blondes and Wish Lists | onehundredfortywords

2. Judy said it… “Vendors should be doing more than responding to the market. They should be doing what they can to push our industry forward.” When companies respond to the market they suffer from too many bright ideas.

   I can’t help but mention that much of what was being discussed was standard in Authorware 15 years ago. Then Authorware got hijacked by the development community who added in all sorts of clever items that kept up with what the market said, but not what learning needed. That development-side interface was perfect. To me.

   1. Yes, that’s the point that I wanted people to take away! Woot!

      Brad, you’re absolutely right about Authorware. The vast majority of tools now are anemic by comparison. So, in a sense, what I’d like it to take us back a decade or two… but push us into the future in terms of delivery format (there goes my HTML5 soapbox).

      Thanks for listening!

3. Pingback: Blondes and Wish Lists

4. Only the Metro version of W8 will drop plug-in support including Silverlight. This is primarily for touchscreen devices. Windows 8 desktop mode will still support plug-ins.

   There will likely always be a place in the browser ecosystem for Flash and Flash-like tools. The magic sauce is progressive enhancement. There aren’t 1 for 1 value or resource replacements for some Flash functions. Not to mention the legacy corporate folks that still hang onto IE6 and IE7. A better model for specifying composition and enhancement that dovetails with tools will cause a big breakthrough in authoring tools. Simply dumping out to Flash doesn’t get it. Neither does ignoring the functional traits offered by tools like Flash and Silverlight.

   1. Yes, as I believe we’ve discussed before, I don’t see much elearning that just couldn’t be done in HTML5. At all. I’m all for using what still has a place, but lack of authoring tools and, to a lesser degree, lack of modern browser adoption are far bigger stumbling blocks for adoption of HTML5 delivery in elearning than the capabilities of the technology.

      I’m very interested in what you’ve written here and below about “a better model for specifying composition and enhancement”, though. Care to elaborate here? Or like I replied below, maybe we can discuss in person soon.

      1. You’re spot on with the current barriers for implementation of HTML5. I still contend that there are a few higher end simulation activities that you’d be hard pressed to replicate in HTML5 consistently and without sacrificing some elements of the experience. Without the tools to develop with, attempting these types of development in HTML5 doesn’t jive in resource investment anyway. Without a doubt, HTML5 is a huge step forward in standard feature support. I’m looking forward to exploring these waters as our organization gets closer to leaving IE6 and IE7 behind. Until then, it doesn’t make much sense to do anything other than prepare patterns that work on these browser platforms while still offering enhancements to features and capability for better tech in the future.

         My definition of composition implies two things.

         First, the standard expectation for experience patterns. I think when most folks think of Self-paced eLearning they think of the slide based presentation model as a composition default. A header at the top, back and next buttons somewhere obvious and consistent, and a large hole in the middle to dump text content, pictures, and other media. In my opinion, this composition default is driving much of the outputs we see in the industry today and is certainly the pattern pursued by most vendors in the industry. If we expanded our composition and didn’t get so hung up on the slide based presentation model, I think we’d start to see more sensible patterns emerge and alternate application models gain popularity to rival next-chained-slides. I think this was (is) one of the great things about Authorware. It didn’t focus on the presentation structure. It focused on the result structure. This encouraged different, and better in my opinion, composition patterns.

         The second implication of composition is structural. This is where enhancement really comes in. When you think about comparing HTML5 to Flash, we automatically think of things that HTML5 can do well and should be feature selected over Flash. Apply that same comparison between HTML5 and HTML4. There are plenty of representations that HTML4 offers in document structure that don’t require HTML5. Equivalents. By considering composition build-up of structure and features, we can offer the best core representation to more platforms more consistently. One of the best things we can do for accessibility is present document structures in text using built in structure tagging (H1, H2, etc..) For someone with limited vision, getting a minds eye view of the structure of a solution is paramount. Back to the composition default of screen based representation. We not only make it more difficult for those with disabilities to visualize structure and big picture when we compartmentalize views, we also make it more difficult for those without this disability. In our attempts to accommodate cognitive load limits, we may be inadvertently introducing a “fog of war” that limits the learner’s progression and uptake. And for learners like me – those that want to make their own filters and not be spoonfed itty-bits – this compartmentalization is detrimental to the experience. By recomposing our expectations and offering reconfigurable filters, I believe we can push the patterns forward by leaps and bounds.

         I’m working on a couple of prototypes using responsive development patterns. This starts with a readable document structure, strategizing text based content first — where it’s appropriate — and building up a single page topic with subtopic areas. This is layered with composition elements within the document structure like activity triggers, video display, illustrations. When scaled to desktop size, it’s displayed like an article if that’s the view style the learner selects. If the learner wants to view the subtopics in isolated mode, they select another mode and they get the subtopics one at a time with a navigation menu. If the learner wants to view it in a slide mode, I’m trying to build in display classes that allow reconfiguration to a slide based format. When displayed on an iPad or other portable device, the display responds in kind by changing the stylesheet. At the upper levels of enhancement composition, we might still use Flash when it’s appropriate or necessary. But by a rule… the addition of these elements can’t destroy the experience by their absence if the audience can’t view them.

         That’s the idea anyway. Use HTML4 for things that can carry messages appropriately. When HTML5 or JS enhancements are required, these are added in another compositional layer. And if we need a plug-in, at the very least we let the user know what they’re missing and what they’ll need to view it but don’t let the absence get in the way unless it’s a critical element.

         Composition and enhancement.

5. Second comment. I think one other thing we can focus on is disambiguating what we mean by design. I get the feeling that both of you are designers with strong development skills (each of which has it’s own disciplined design traits).

   I see design for eLearning in four distinct but overlapping categories. Instructional Design, Communication Design, Experience Design, Technical Design. These problem solving verticals contribute to the Design side of the triangle. The other two sides are Inputs and Execution. The point here is that we seem to often confuse different categories of design to the detriment of the output.

   It’s my feel that driving ISD (focused ID discipline) towards ends that they may not have affinities for is a waste of energy and resources. I see way too many ID’s that really enjoy playing graphic artist but completely suck at it. Nothing burns me more than seeing someone expend hours at a value that is less than half the rate they are charging. This equates to burning hours at a double rate with poor results. Just doesn’t compute.

   In this way, I think putting together a wishlist for an all in one tool is foolhardy. And I think that many designers wouldn’t use features that would be perceived as constraining to design. As an ISD, I think your best tools are under a bit of skin and bone, located behind the eyes. On the other hand, some standard encapsulation for design communication, a common lexicon, would be beautiful. If we had some standard data elements, a natural and automatic workflow to connect throughout the process could become a reality. I have little faith that the field will come to agreement on a disciplinary lexicon. Just the way things are.

   As an experience and communication designer / developer who has migrated towards both the instructional and technical areas over 15 years, I see how the tools haven’t really driven us forward. I think the key is tiering the types of service we need to expect from these tools and not drive consistently towards “easy to use for the lowest common denominator.” In our organization we’ve built a two tier system for development tasks. The first tier is the easy button toolsets for the casual or all in one developer – that developer that can do something “just good enough” with a tool that doesn’t require a lot of time investment. The second tier is the forensic developer, web developer, application developer.

   The industry is so focused on the one-person shop and sadly the bar is pretty low – which is exactly where we should expect it to be. Specialization has value. A designer / developer with strong skills across all four categories (ID, CD, ED, TD) is truly rare. We can’t expect someone to build a tool around a rare category of designer. But I do think we can make the casual / just good enough tools better and tailor some tools that dovetail with better processes.

   1. Steve, thanks for responding so thoughtfully. There’s a whole lot of good stuff there. You’ve probably now contributed as much time to this episode as Brian and I have, so please reply and link up your drink selection.

      A few responses…

      I don’t think you’re going to find anyone in the industry who agrees with you more than Brian and me that a designer’s brain is his or her most important tool. I knew when we started this podcast that we would always be answering the contention that tools are secondary to skill, with the implication that we aren’t focused on the right target. If that’s your intention, well… thanks for pushing my other soapbox into place.

      I think our focus on tools is important because the state of our tools is pretty dismal overall right now, and many — maybe even most — elearning designers and developers don’t even know it. There are some tools that are really powerful, there are some that are easy to use, and there are (I hope) many bright spots on the horizon. But there are some that I would contend are actually damaging in how they influence design and decrease efficiency, and therefore damaging to learners and to our industry. I believe in the value of good tools. I expect my doctors, my accountant, and my barista to have them and use them skillfully. I see no reason to expect less from instructional designers and developers.

      I see lots of people in our industry working to improve people’s design skills, and that’s awesome. I see very few people calling out vendors for perpetuating the creation of buggy, inflexible, even harmful software and then marketing these tools as replacements for instructional designers. I guess that’s where this podcast comes in. 🙂

      I completely agree that there is value in specialization, but the sad reality is that there is a preponderance of one-person shops in our industry right now, and that’s just how it is. I can’t do much about that, but I do think it’s possible for tool vendors to help these people out more than they currently do. In fact, I know it’s possible, just from seeing some tools that are in development. Where I’ve see more harm in combining roles is in, as you mentioned, expecting your instructional designer to be the graphic designer, as well, rather than in expecting the instructional designer to also do instructional development. Our industry has come a far way in making development easy; now it’s time to balance that with more power, stability, and flexibility.

      There are so many directions we could take this conversation. If we’re at the same conference or meetup anytime soon, let us know and we will.

6. Pingback: The ToolBar, Episode 6 – Blondes and Wish Lists | onehundredfortywords
7. Pingback: The ToolBar, Episode 10 — Tying Down the Flappy Elements | onehundredfortywords

Comments are closed.