Survey Slate allows organizations to host custom surveys for end users on their own AWS infrastructure.

Tom Larkworthy

categori.se

Survey Slate | Technical Overview

Saneef H. Ansari

Survey Slate | Common Components

Survey Slate | Survey Components

Survey Slate | Admin Tools

Survey Slate | Admin UI

Survey Slate | Designer Tools

Survey Slate | Designer UI

Survey Slate | Survey Filler UI

User Guide for Survey Slate Designer

Aaron Kyle Dennis

Survey Slate | Styling

Tachyons CSS and some extras

Survey Slate

The most up to date version of this notebook is hosted at https://observablehq.com/@adb/survey-slate-styling

Let's see whether or not I messed up ;) attempting to override Tachyon's line height defaults to allow a more 'compressed' look.

Don't do this, your link and style elements will be wrapped in a span.

Instead use @import and @media in a single style element. Also, the media attribute serves no purpose here, unless your intend was to explicitely exclude "speech".

Fabian Iwand

It's a bit cumbersome to try to trace through these various embedded style definitions.  Is there any way we can abstract these or gather some basic setting or places where we're adding custom classes into a  'style sheet' page--particularly for our 'demo survey' / template?  Also, I can't figure out how to set the colors for the non-active links.  I see in Tom's current generated survey they're visible as white; here's there's grey and hard to see.

Styling and layout is specified programmatically. You can't really "template it out" beyond choosing some colors. The idea that we would have a few different style notebooks. This one is specifically for the GESI usecase.

It seems more manual than programmatic?  That is, you're manually hard-coding in style values here, yet the purpose of this function is a to generate the page menu.  Even for the specific 'GESI' template, we should be able to abstract these definitions and allow a 'configuration' space.

When you say 'configurable', what is the extend you like to configure? Is it only colors, like:
- brand-primary
- brand-accent
- text
- ... similarly a fixed set of things (like variables)
etc?

Or, are you looking to do Tachyon classes based like you have done above?

Since we already have all these amazing preview options, I guess my idea is to expose a few 'parameters' that would affect the look and feel of a template.  While lots of this is trivial, I find that myself and others are far more excited for a tool when aesthetic aspects can be manipulated.  If we offer the 'default template' and 'gesi style sheet' both as examples with our 'application launch', and where users can make minor but visual adjustments to the 'default' and save (maybe even re-import) their style config, I bet it would really help more people to want to play around.  I realize I'm imagining that people even find and read this :P   I am still trying to figure out how to get ADB to take over some marketing responsibilities...

Sorry - maybe a more direct answer: I was thinking of just Inputs.color().  It's great that ADB has branding, and great we're using that for GESI template :)

The images aren't working very well with the centered text content: it's not possible to see the scene.  Also, the 'background-size: cover' setting extends into the menu area, so that the tops of image are clippped.  Would be good to re-think use and placement of images so that they add interest and value.  My porotype sought to ensure that images were completely visible for most viewports... though things broke down for larger browsers where the questions felt 'too small' and view area was dominated the the image.

Thinking about this further - the alignment is just a choice, and right, center, or left is an easy choice to expose to people.  Perhaps images should similarly just be a choice, and alignment also exposed to the user.

The Square brackets (`[]`) you see within classes are only to group related classnames. A downside of using Tachyons or TailwindCSS is that it becomes harder to read style. Just to pacify that problem a bit I tend to group classes with square brackets. In this notebook, you'll see color related classes as a group, spacing (padding and margin) as another group,...

@saneef Have you considered using line breaks instead? Both [ and ] are valid class names, and if someone forgets the surrounding whitespace they accidentally end up with a different class name (one including the bracket in its name).

I'd imagine that this sort of thing is a perfect use case for a helper, e.g.:

function g(...args) { return args.map(s => `[ ${s} ]`).join(''); }

<span class="${g("pl2 dib mr3 mt1 mb2", "f4", "white")}">

That way you can change the style of separation at any point (and also remove it), without having to change your existing class assignments.

I would need to check on this, but in our various notebooks the initial views will often show errors prior to the use authenticating. Generally speaking, you're correct to point out that we can do better in flagging this and helping better orient those wishing to engage with the application and its code.

Yes, the error is expected - it will resolve after entering credentials.

Do the errors here affected the functioning of the survey?

If the error is on `layout`, yes it will affect the functioning of the survey. Most likely it caused when the questions layout is missing. See https://observablehq.com/@categorise/surveyslate-designer-tools

Hi Saneef!  Thanks for responding! I'm using my credentials and toggling both the dev and production versions of the gesi-self-assessment, as well as our various test projects and the error here persists -- here at least.  The flagged bit is the `sectionView` function where we use .map.  In the example code above, `surveyConig' is valid, as are both `new Map([...questions.entries()].map(([id, q]) => [id, createQuestion(q)]))` and `d3.group(layout.data, d => d['menu'])`, so the error isn't with the inputs but rather with this function (also not working in the adb-specific version referenced in Tom's comment above). I've made a lot of progress porting this application to Framework.  I'll push some updates soon and will share a link once I do.  Looking forward to deploying a few new surveys! :)

Ok, I got it: For the purposes of this example, we just needed to change the hard-coded `sectionKey` to "nolayout" and the example renders correctly.  Thanks for pointing me in the right direction!

viewof exampleSurvey = Error: Problem updating calculation 'undefined', reason: Cannot read properties of undefined (reading 'control')

casualty of the model refactor, should be ok now, though it does fail until the data is properly loaded.

Can we link the values here like 'mainstreaming' and 'operation' to their corresponding identifiers elsewhere?

Where are we getting 'section'?  Looks like it's from `sections = d3.group(layout, d => d['menu'])` - so we're staying here that if we have a section from our layout that includes this tag, append this image to it.  I suppose the question is - to make this easy if people have a survey, and have images, and wish to link the images to their survey, can we expose a list of available section IDs that they can select to link images (if we're not giving up on support for images)

These look fine here, but they're coming through very pixelated and weird in the preview under 'Survey Filler' and generally we've changed the survey layout from the prototype version such that these pictures no longer fit the presentation context.

Dont' use multiple awaits, they will cause your code to run synchronously. Instead use a helper like the following:

async function resolveObject(obj) {
  return Object.fromEntries(await Promise.all(
    Object.entries(obj).map(async ([k, v]) => [k, await v])
  ));
}

Then do:

images = resolveObject({
  "mainstream": FileAttachment("core_mainstream@1.jpg").url(),
  "operation": FileAttachment("core_operation@1.jpg").url(),
  "intro": FileAttachment("intro@3.jpg").url(),
  "default": FileAttachment("core_intro@1.jpg").url(),
})

Thank you! Changes applied. As a bit of an aside, I'd be interested to delve deeper into use of background images in the application.  I imagine that there are lots of avenues for improvement, like creating 'image stacks' that would serve out images based on device screen size/resolution.  Also our original concept was for images to be randomly generated on clicking the navigation menu.  All suggestions welcome :)

This loads Tachyons together with some of our own extensions, like brand color classes, and extra utility classes.

Different combination of the above 'brand', 'accent', and 'text-on-brand' should give some variation on color schemes.

Is this the place where we would add overrides to Tachyons?  E.g. to change the default line height to:
```
.lh-copy {
    line-height: 1.1;
}
```