From 3e04b1d08d7c2f14b6f28160aad72edd95944e74 Mon Sep 17 00:00:00 2001 From: Tim Otten Date: Tue, 18 Sep 2018 23:03:33 -0700 Subject: [PATCH] Update philosophy.md --- ext/afform/docs/philosophy.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/ext/afform/docs/philosophy.md b/ext/afform/docs/philosophy.md index d6b074431c..28768f32ab 100644 --- a/ext/afform/docs/philosophy.md +++ b/ext/afform/docs/philosophy.md @@ -1,17 +1,16 @@ # Philosophy, Beliefs, Assumptions -Afform is generally grounded in a few beliefs.. +Afform is generally grounded in a few beliefs. ## Leap by extension Afform represents a major conceptual change in how core forms are developed. It is incubated as an extension that can -be enabled or disabled to taste. The aim is for oother extension using `afform` can incrementally override/replace -particular forms in core. +be enabled or disabled to taste. The aim is to write further extensions which (a) build on afform APIs in order to (b) incrementally override/replace particular forms in core. ## Features and user-experiences evolve in funny workflows If we could sit down and define one true, correct version of a "Donation" form, then our lives as Civi devlopers would -be easy: draw a mockup, write code, ship, and retire. But we can't -- because Civi users and integrators engage with +be easy: draw a mockup, write code, ship, and retire. But we can't -- because Civi users / integrators / developers engage with the system creatively. They aim to optimize conversion-rates, to integrate with donor journerys, to question how each detail makes sense in their situation, etc. That means switching between open-ended donation amounts, sliders, radios, etc; revising the language and layout; maybe adding an informational question or newsletter opt-in. @@ -26,6 +25,9 @@ This is *not* an argument for maximal customization or maximal decentralization. must still communicate and exercise judgment about the best way to approach each problem. But there are legitimate instances for each workflow; given that each will be sought, we want them to be safe and somewhat consistent. +The aims are *not* achieved by developing every feature in-house. Rather, this is conceived as an effort to use +existing tools/frameworks while relaxing workflows. + What distinguishes `afform` from the original form architecture (Civi's combination of HTML_Quickform, Smarty and Profiles)? Each of those workflows has been given some consideration upfront with the aim of providing a *consistent, unified model* -- so that the same data-structure can be pushed through any of those common workflows. -- 2.25.1