So with what seems to be the sound nails being hammered into Flash's coffin... what's your strategy going forward? How are you preparing for development in 2012?
Will this change any of your current projects?
For me, I did spend about 30min this morning checking out the learning curve on HTML5... but no drastic changes yet.
More of *this* banter? Interesting development. However, I think we should keep in mind that just because development for the device market is going to stop (half the market share didn't support it anyway) doesn't mean that the tool or technology is dead...
Everyone is looking for a sensational headline to feed the hungry trolls on either side of this ill-informed debate in what seems to be more of a fanboy vs. fanboy argument than anything that makes any sense whatsoever. A few facts that these hatchet jobs seem to leave out:
1) Mobile isn't everything. The desktop isn't going away any time soon. Mobile is important. But so is the desktop.
2) The mobile experience often considers different factors than the desktop experience. We really should consider this as we argue about tools and technology.
3) The tech isn't even there yet for HTML5. As far as I know it's not completely agreed upon yet. HTML5 is awesome. I love the idea of supporting stuff through the document structure. But what the technology promises IS NOT just HTML5 (JS and CSS3 are big players). There are other technologies involved to pull off the best samples available. Apple's samples, for example, don't really work consistently on other browser platforms and make heavy leverage of JS. Even so, the equivalents aren't always there for things Flash has matured to do over the past decade plus. It will. But it's not now. So I really don't understand the "this kills that" argument. It's WAY too early for that.
4) Extending the last item, the tools aren't there yet to support equivalent outputs with equivalent effort. The Flash IDE has evolved to support a broad set of interaction types. If folks expect a) consistent behavior across platforms and b) the exact nuances of a Flash based output replicated in HTML5, I think they will be disappointed. HTML4 / 5 / CSS cakes can do so many things better than Flash - in my opinion. But it's not *everything*. And expecting it to get done in the same amount of time with the same level of expertise is a fantasy (for now).
5) Browser support is historically inconsistent. Not to say it will be like that in upcoming versions, but a point goes to Flash for consistent behavior across platforms that support the plug-in than the standards soup. Just less headaches for a developer. Heck, my organization JUST moved from IE6 to IE7. Any guesses how much HTML5 support there is for IE7? The answer is... not much.
6) Flash has been misused and abused. It can be built efficiently and appropriately or less so. Flash can work efficiently on devices when it is DESIGNED and CODED with device limitations in mind. HTML5 and JS will be abused no less.
While I don't get the argument of this vs. that. I think it's a fools argument manufactured to draw out more fools to argue one is better than the other. I do get that there are some things that can be done more sensibly by looking at Web standards and future friendly content architecture. Here are our current rules:
1) Don't use a more complicated or encapsulated technology when something simpler will suffice. This means, don't use Flash unless you have a darn good and defensible reason to do so.
2) Think five and ten years in the future. What does that support look like? For our organization, I believe Flash support will still be available. It may not be the most popular at the time, but I think it's a safe bet that Flash will still be around even if it's not as popular as it is today. HTML5 (or 6, 7, 8 XLZIPPITY) will get better, other technologies will come along. Things will change. So, what?
3) Think universal accessibility. This means both people and devices. HOWEVER, this DOES NOT mean that just because the iPad is hot right now that we focus on accommodating that platform exclusively. Make things work as many places as possible.
Here's something I wrote awhile back that describes, what I think is, a more sensible approach. I call it composition and enhancement and these aren't really original ideas, but these support the rules we're starting to think about as we produce content...
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.
4 Replies
More of *this* banter?
Interesting development. However, I think we should keep in mind that just because development for the device market is going to stop (half the market share didn't support it anyway) doesn't mean that the tool or technology is dead...
Everyone is looking for a sensational headline to feed the hungry trolls on either side of this ill-informed debate in what seems to be more of a fanboy vs. fanboy argument than anything that makes any sense whatsoever. A few facts that these hatchet jobs seem to leave out:
1) Mobile isn't everything. The desktop isn't going away any time soon. Mobile is important. But so is the desktop.
2) The mobile experience often considers different factors than the desktop experience. We really should consider this as we argue about tools and technology.
3) The tech isn't even there yet for HTML5. As far as I know it's not completely agreed upon yet. HTML5 is awesome. I love the idea of supporting stuff through the document structure. But what the technology promises IS NOT just HTML5 (JS and CSS3 are big players). There are other technologies involved to pull off the best samples available. Apple's samples, for example, don't really work consistently on other browser platforms and make heavy leverage of JS. Even so, the equivalents aren't always there for things Flash has matured to do over the past decade plus. It will. But it's not now. So I really don't understand the "this kills that" argument. It's WAY too early for that.
4) Extending the last item, the tools aren't there yet to support equivalent outputs with equivalent effort. The Flash IDE has evolved to support a broad set of interaction types. If folks expect a) consistent behavior across platforms and b) the exact nuances of a Flash based output replicated in HTML5, I think they will be disappointed. HTML4 / 5 / CSS cakes can do so many things better than Flash - in my opinion. But it's not *everything*. And expecting it to get done in the same amount of time with the same level of expertise is a fantasy (for now).
5) Browser support is historically inconsistent. Not to say it will be like that in upcoming versions, but a point goes to Flash for consistent behavior across platforms that support the plug-in than the standards soup. Just less headaches for a developer. Heck, my organization JUST moved from IE6 to IE7. Any guesses how much HTML5 support there is for IE7? The answer is... not much.
6) Flash has been misused and abused. It can be built efficiently and appropriately or less so. Flash can work efficiently on devices when it is DESIGNED and CODED with device limitations in mind. HTML5 and JS will be abused no less.
While I don't get the argument of this vs. that. I think it's a fools argument manufactured to draw out more fools to argue one is better than the other. I do get that there are some things that can be done more sensibly by looking at Web standards and future friendly content architecture. Here are our current rules:
1) Don't use a more complicated or encapsulated technology when something simpler will suffice. This means, don't use Flash unless you have a darn good and defensible reason to do so.
2) Think five and ten years in the future. What does that support look like? For our organization, I believe Flash support will still be available. It may not be the most popular at the time, but I think it's a safe bet that Flash will still be around even if it's not as popular as it is today. HTML5 (or 6, 7, 8 XLZIPPITY) will get better, other technologies will come along. Things will change. So, what?
3) Think universal accessibility. This means both people and devices. HOWEVER, this DOES NOT mean that just because the iPad is hot right now that we focus on accommodating that platform exclusively. Make things work as many places as possible.
Here's something I wrote awhile back that describes, what I think is, a more sensible approach. I call it composition and enhancement and these aren't really original ideas, but these support the rules we're starting to think about as we produce content...
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.
Thanks Steve, agree with you as usual, however looking at the corporate/goverment market I dont see much changing soon, a lot are still using IE 6!
We sometimes get too caught up in the technology, instead of looking at the learning that we are trying to deliver.
Interesting points.
One things for certain, the web experience will be different in the years to come. It always is.
Phil, I'm reading more about support for specific industries (advanced gaming, etc.)
I do believe, as you say, the corporate/government markets will keep Flash support strong going forward.
This discussion is closed. You can start a new discussion or contact Articulate Support.