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 :)
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)
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.
'bg-white' is tachyons specific. maybe it would be interesting to provide a dropdown select list of 'official' options? https://tachyons.io/docs/themes/skins/
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.
@aaronkyle I have tweaked our survey filler main content alignment to the right, so that we can expose more image on the right like in the above screenshot. Also, minor fixes to avoid cropping on the top part of the images. It's not perfect. But it is good enough, I think.
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 :)
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".
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.
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!