Antranig's review of the keyboard accessibility plug-in demo
http://issues.fluidproject.org/browse/FLUID-3799
raised the same question that came up in my mind as I was creating the demo:
Should our demos themselves be implemented as a Fluid component? At the time, I
vacillated between a) benefitting from and demonstrating the power of the
framework on the one hand, and b) keeping the demo focussed on the thing that
was being demo'd on the other hand.
Michelle and I discussed the issue, and in the end we felt that the information
we were trying to focus on - how to use the keyboard accessibility plug-in -
would be more clearly conveyed without the trappings of the rest of the
framework. We, as Fluid developers, are very familiar with the structure of a
component, and so we are quite comfortable looking at code that is structured
this way. But I think we forget that for developers who are not familiar with
the format, it can take a bit of effort to get used to (I imagine Mike and
Gollam might concur). If the keyboard accessibility plug-in demo is implemented
as a Fluid component itself, then users who are not familiar with the framework
must spend extra time and effort to understand the framework before they can
get to understanding the thing they came to the demo to learn: the keyboard
accessibility plug-in. Or they might not take the time to learn about the
framework, and misunderstand the demo to assume that the framewor
k features are a requirement for using the plug-in.
As I said above, I vacillated about this. I do agree with the goals of
illustrating best practices; and these days, it feels very odd to write code
that doesn't use the framework's features. I'm still not sure which is the best
way to go.
There are at least two other demos that use a similar non-component style to
demonstrate a component (InlineEdit and Progress), so I think this is a
conversation worth giving due consideration.
What are other people's thoughts on this issue?
--
Anastasia Cheetham Inclusive Design Research Centre
[email protected] Inclusive Design Institute
OCAD University
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
