Skip to end of metadata
Go to start of metadata

Wikified notes from etherpad of Community Meeting of 8th July 2015 (original at https://beta.etherpad.org/p/Infusion_Community_Meeting_8-7-15 )

Introduction to Infusion

1. What is Accessibility? (everyone)
2. What is Infusion? (everyone)
3. Accessibility and User Creativity
4. Infusion example: temperature converter
5. Infusion's idioms and what they're for (applications as, themselves, bodies of state)
  • IoC and IoCSS
  • Lensing and the Change Applier (Model Relay)
  • Requirements for Lensing - naturally aligned, publically addressable (observable) state
  • An outgrowth of natural idioms on the web (the DOM and REST)

ETHICS

- why Infusion is different from everything else you think you know
- how Infusion relates to things you think you might know, like Ruby on Rails or Node.js and Express
- how to change things without changing them
- how to fork things without forking them

What is Accessibility?

  • Engage with People and Things
  • A philosophy of design
  • Use by the widest possible set of devices, abilities, and preferences
  • Qualities of software: openness, separability, quality of code
  • Jutta-ism: the ability of a system to accommodate the needs of its users
  • Accessibility is "good design"
  • The capabilities provided by things, and how they can be adapted
  • "Closing the gap" so that everything can be used
  • Communicates what is expected between user and the systems they use
  • systems also communicate their expectations to users
  • communication as affordance
  • The intention of being inclusive, of not leaving anyone out
  • A lack of accessibility is bad design, but the converse might not be true
  • i.e. not just the bare minimum of accessibility, but the greater user experience
  • User, context, and task or goal
  • Removal of all the barriers in the "channel" between the user and their goal in a specific context
  • Making system invisible
  • Accessibility means usability by anyone, regardless of disability, language, whatever else in as many situations as possible. And pleasurable to use.
  • Built from the ground up
  • Not removing barriers, but the system supporting equal user experiences and autonomy; the system supports independence
  • An intention or worldview or philosophy or way of being in the world of being mindful that the audience of the thing you're making is probably bigger than what you can think of
  • Receptivity to needs that you haven't considered
  • The ability of people to continually express themselves, and to create networks between their expressions and those of others

What is Infusion?

  • framework for building flexible, adaptive applications and software systems using JavaScript and the Web
  • A code framework separated into different functional parts so you can mix and match to easily build accessible things
  • A code system--JavaScript and HTML--that we put together so that people can take modules and put them together to build their own accessible app or website
  • An open modular system designed to be highly configurable so that anyone can modify and adapt it so that people can create systems, applications, components, etc. that meet their specific use cases and needs
  • Open source JavaScript framework. Hopefully it allows the user to avoid some of the common pitfalls that you can encounter using the JavaScript language itself.
  • Infusion is something that Justin and Cindy help us with. It gives a quick shortcut for improving things. A very challenging tool.
  • Not a cold remedy.
  • Components that can have all their default parts and features taken apart ("in their underpants") and then different features, styling, and parts can be replaced and added ("in top hats and tails")
  • WHAT SEPIDEH SAID
  • Our repository for all the experiences we've gained about how to make applications accessible, at least where that experience is expressible in code. More than anything else, it's about code, but it's also about documentation, our community values, and so on. Wherever we learn something about how improve the design of an application and how to achieve the values of accessibility, so that people who come after us (including us) can get the benefit of this experience
  • Something to wrap our heads around.
  • Built on top of jQuery
  • Not like anything else we've seen before in terms of what it does
  • A "strongly opinionated" framework with accessibility baked in from the start
  • Something that strikes a midpoint of the LISP-like convention of "everything is a data structure" and the JS-like "nothing is a data structure convention", and thus much easier to transform
  • The framework that the Fluid community was forced to make to realize our worldview of extreme flexibility and adaptation on all levels including creators, integrators, and various types of users
  • It is a way of thinking about programming that is embodied in an actual tool for programming with - both a mentality and a design approach applied to technology and programming, as well as being a concrete framework. What I want to say is that Infusion brings users/people out of what we traditionally view as a role of consumption/use and puts them in a position where they can be actively engaged in the creative process. We turn software into something other than a product - a medium.
  • Supports 1:1 design, not design for the averages
  • Inclusive design - not universal design

Code vs. Data

  1. Different audiences:
    1. Code: the runtime, the compiler, other developers
    2. Data: processable also by the machine, and easier to process without needing a whole language runtime--it's possible to look at data and understand it without having to execute it
  1. Once you can extract meaning from data, you have the ability to process data to (e.g.) present it in different ways, make translations to it, etc.
  2. In 1958, LISP WAS CREATED BY ACCIDENT
  3. In 1996, JSON WAS CREATED BY ACCIDENT

Intention

  • code embodies excess intention because you have to say more than you may have needed to
  • sequentiality: lines of code commit to a definite execution order
  • artifact boundary intention: part/whole distinctions don't always match amongst different users/developers/layers of a system
An Infusion application:
    
This defines what we call a grade - which, taken most simply, is just "a named block of JSON". The name is considered part of a universal, global shared namespace - assigning names to functions (or capabilities).
    
fluid.defaults("examples.simpleRelay", {
    gradeNames: "fluid.component",
    components: {
        celsiusHolder: {
            type: "fluid.modelComponent",
            options: {
                model: {
                    celsius: 22
                }
            }
        },
        fahrenheitHolder: {
            type: "fluid.modelComponent",
            options: {
                modelRelay: {
                    source: "{celsiusHolder}.model.celsius", // IoC reference to celsius model field in the other component
                    target: "{that}.model.fahrenheit",       // this reference could be shortened to just "fahrenheit"
                    singleTransform: {
                        type: "fluid.transforms.linearScale",
                        factor: 9/5,
                        offset: 32
                    }
                }
            }
        }
    }
});

From Chat:

Alan: 20:43 sequential intention considered harmful!!

  • No labels