Development Blog

up agin it

2019-03-25T11:01:00.002-07:00

2019-03-25-website-log-deadlines

on a deadline, assets not forthcoming, material being added faster than I can even talk about completing it, laptop charger left in London, new one doesn’t come until who-knows-what-time tomorrow.

this is great

OK. well, there’s nothing to do but keep calm and carry on, much as I hate myself for saying it.

while I’m waiting for things to resolve, asset-wise, I’m going to get on with the new zigzag followed by the testimonial “carousel” (which will be CSS animation).

zig zag

this is pretty simple stuff and my time is short, so I’ll just make the observation (I’m sure I’ve said it before) that ‘mobile first’ is a design consideration not one of implementation. I have to look at both screens in order to start implementing the design.

I also, slightly desperately under the circumstances, start adding global text classes to match the designs and (what’s available from) the styleguide.

I realise these really are global classes as opposed to utility classes because 1) they’re not scoped to a component or page 2) they have properties like line-height and letter-spacing baked in instead of conferred by small, atomic classes.

hey ho.

another complication with this is - what is the semantic status of those little grey headers? in a visual hierarchy they’re like labels, but in a page outline or for screen-readers, they ought to be treated as, what, <h2>s?

…whereas the class I’m applying to the ‘blurb’ (eg “hassle-free admin”) is named heading-3. Gawd.

It’s awful, because it’s the opposite of what should be happening. The class names should be semantic in the HTML (in the sense that they describe the function of the element within the content) and provide hooks for styling. Actually what I’m doing is naming the classes based on how they look rather than how they function, but not even doing it in a way that’s scoped or descriptive. sigh.

<h2>is being overwritten by some media query elsewhere in the code. I’m going to switch it to a <p> to get the job done and put it on my todo list.

11:48

because I’m trying to limit how much flexbox I use (and not use grid at all) to increase my confidence of IE behaviour, I’m using float on an image rather than any unlikely flex-item self-ordering.

problem: when using float the child ignores the margin-auto rule set on its container.

~~solution : give the image margin-auto inside a flex container (which I need anyway for mobile).~~ nope

~~solution: put the image inside the container~~ nope

13:17

after ducking back onto the hero for a while, I’ve come back to this and am now going to try just using the flex order property - it looks as though IE11 might support it enough, and this float stuff is just a K-hole.

17:46

Under pressure, so I’ve not made a blow-by-blow account, but I got there. I doubt I’ll have the impetus to do a proper analysis, but it was an interesting exercise.

I’d have been within my rights, I think, to ask the designer to make some changes to make this easier, but in the end I was piqued by the challenge of something that looks so trivial.

Basically, I did the mobile design first, placing the image (which is the thing that is out-of-flow) as the first child of the flex-column. I then re-positioned it by making the heading column element order: 0; and the image order: 1;. I don’t know if it’s strictly necessary to specify both of those, but that’s what I ended up with and I haven’t gone back to clean up yet.

For the desktop layout I use a media query to float the image left and set the container’s display property to block.

Not super-clean and elegant, but not the jankiest thing I’ve ever written either.

In other news, the PM wanted rid of this red line that was leaking out under the hero 'cause the background was set to a solid color as fallback for IE11 < 767px where the background image doesn’t resize properly and the text becomes white-on-white.

The solution came from browser hacks and it looks like this:

@media screen and (-ms-high-contrast: active), (-ms-high-contrast: none) {
    .homepage-hero__bg {
      background-image: linear-gradient(334deg, #cb2e63, #ffec87);
    }
  }

I mean, I know it’s not really legit, but it’s pretty clever. Lets me replace the whole svg bg image with a gradient for IE and dispense with background in the normal code.

todo

make the HTML semantic for headings and text (homepage, but this principle should be extended throughout).
conflate the content block styling for each section inside the section class.

2018-10-07-website-log-CSS

2019-03-25T09:56:00.001-07:00

2018-10-07-website-log-CSS

PROBLEM: flexbox is having a distorting effect on images
SOLUTION: align-self: center on child img elements, as per this.

LESSON: DO IT IN DEV TOOLS!

INVESTIGATE: flex-basis

UPDATE (2019-03-25):

for IE11 getting unwanted horizontal stretch, use flex-shrink: 0;

source

build the right thing 2

2019-03-19T03:09:00.001-07:00

2019-03-18-website-log-carousel

Here’s where I’m at:

The images are placeholder and the text changes don’t line up with the image changes, obviously, but both of those can be easily tweaked.

Today’s work is to get the desktop version working per design (in a visual sense at least)

Aaaand it immediately starts looking smelly to me… I’m changing the behaviour from “being invisible” to being visible in 4 different screen locations and having a different animation… Nevertheless, I’m going to get into it and see how bad things get.

placement

let’s get the layout done.

I want these bullet points in two separate columns.

I need to disable the animation…
Then I figure out that the bullet points don’t flow in the right direction… ignore this for now.
And the image needs to be in the middle of the block of HTML if it’s going to flow properly…
this whole thing’s starting to feel like it’ll be desktop first again by the time I’m, finished!

build the right thing

2019-03-18T02:35:00.002-07:00

2019-03-15-website-log-compromise

This is the first of the two things (on this page!) that I have pretty much no intention of implementing the way that’s been specified. I’ve indicated to the PM that if we want to hit this deadline we’ll need to make some sensible compromises and reminded him of the mess we got into when we over-reached with the cost calculator.

The problem, without going into it in too much detail again, is that our site is a blogging platform with some custom pages worked in.

We need to keep things simple. If we must have a carousel it needs to be a vanilla carousel from the UI library we already have as a project dependency. We’re not in a position to create bespoke UI to match whatever comes out of the designer’s head.

I’m told this is intended as a ‘slider’ which I think means carousel.

I’m going to make a container and have some CSS animation cycle though images, see how they like it.

log

So… I think I’m going to practice what I preach and start this bad boy mobile first - looks likely to be easier than rejigging everything at the end.

Handy to have the desktop breakdown done first though.

So I guess I’ll tear into it and try to get the placeholder stuff up and resembling design.

git workflow

2019-03-12T05:54:00.001-07:00

2019-02-16-git-workflow

new develop branch alongside master
merge requests are small, focused, easily reviewable
reviewed on their way into develop so can then be included or omitted from a subsequent release without further review

merge process for master

assuming develop is where you need it to be
update the changelog and version, add, commit
checkout master and merge:

git merge develop --no-ff

the --no-ff flag is ‘no fast forward’. This creates an additional commit that will serve as an artifact of the release (since develop will continue to be developed upon).

[Q: how to cherry-pick commits in develop if it turns out we don’t want to include them?]

Now add an annotated tag to the current commit before pushing:

git tag -a v1.10.0 -m "live-2019-02-14"

push it to the remote repo. build and release

go back into develop and git merge master to fast forward and get things synced up.

continue working on develop.

Process summary

>develop $ git pull

Update version and changelog, commit, push.

>develop $ git checkout master
>master $ git merge develop --no-ff
>master $ git tag -a v1.10.0 -m "live-2019-02-14"
>master $ git push
>master git checkout develop
>develop $ git merge master

2019-03-11-website-log-analytics

2019-03-12T04:16:00.002-07:00

2019-03-11-website-log-analytics

Lots of stuff needs done in a workmanlike way today.

Top priorities for this morning:

~~resolve merge conflicts and get MRs fixed and into develop~~
~~analytics on pricing page buttons~~
~~pricing page UI tweaks to enable release~~

09:48

catch up with LS about day/week plan

10:10

Going to try to resolve merge conflicts locally. Not sure about this.

10:28

I hate this. I accepted incoming changes and the layout got all messed up.

I’ve just tried accepting both changes and I got duplicate UI all nested inside itself weirdly. Going to try accepting current changes and see what goes wrong.

Well, that’s the best, but I lose a bunch of styling and I get the feeling I’m wiping out all the gains of the previous MR.

Going to try to deftly disentangle these and get the best of both worlds.

10:37

So, gulp had failed silently somewhere in that process, which I realised after reset HEAD --hard did not restore the styles I wanted.

Now I’m thinking maybe I want to accept current changes on the pricing page HTML and incoming changes in the stylesheet. Let’s give it a go.

10:55

No, this is a nightmare. I don’t know what’s going on. I’m going to accept all my current changes then reproduce the changes of the previous MR. It’ll be quicker than sorting this out.

11:07

Reverted the previous merge on gitlab which removed conflicts so I could merge the substantive branch. All good. Now I just need to reproduce the changes from the reverted merge. I’ll do that in my current branch and then update.

12:13

Man, what a drag. All done, at last, and I think it’s OK. Annoyingly, I’m fixing things to a standard that I know is going to be revised in changes coming down the line from the new homepage.

It’s really a tangle when you work in different branches at the same time.

Now I’m going to take a lunch break and get into analytics afterwards.

12:36

Back with lunch. I actually think I’m going to tweak some more UI over lunch. I want it to be releasable today if possible.

14:41

Gawd. I think I finally got the page elements aligned and scaling properly. It’s a real guddle. I’m trying to abstract sizing and margin rules out of the components to the page level. It feels like the concept of “layouts” is becoming real for me now.

The next phase, when I get hands on with whatever the design system parameters are, will be to take those page-level rules and raise them up to generic CSS.

In the meantime, I’d better get started on the analytics.

15:24

That was pretty painless… assuming it works. I’m waiting for validation (who isn’t?).

PRICING: UPDATED TO DO

~~first jargonbuster term button should be focused on landing~~ autofocus acts as a page anchor, so I just added the active class and styled it
~~firefox and safari button focus missing~~
~~group life button change book a demo to get a quote~~
~~point get a quote… somewhere else?~~ nope
~~how to autofocus style without anchoring the page landing?~~

2019-03-04-website-log-tabs

2019-03-05T10:37:00.002-08:00

2019-03-04-website-log-tabs

When things are going well for me I tend not to document my progress. It makes sense, I suppose, since the main value is in the process of overcoming problems.

Last week I started implementing this tabbed product card for the revamp of the pricing page:

Stage 0 - planning

Analyse the design across desktop and mobile designs and get an idea of the component hierarchy. This all looks pretty straightforward as far as content goes.

I’m paying particular attention to how these elements behave across desktop and mobile. By giving them identities up front I can start to reason about them in a way that will hopefully avoid confusion down the line.

In this case it’s notable that columns (green “contentBlock” in the above) themselves stack into a column on mobile and change to full screen width.

There’s some fairly arbitrary positioning changes between desktop and mobile. Text in the first column gets center-aligned on mobile, text in the second column remains left-aligned, except for the button which is right-aligned on desktop but becomes center-aligned on mobile.

Even that’s a simplification if I take the designs absolutely literally, but there’s some scope for adjustment, I reckon, so I’m not going to worry too much about it.

Stage 1 - tab functionality

I tried van11y and tabby and another (tabsy?) that I can’t be bothered looking up. It was probably some error of mine that they didn’t work for me, but I couldn’t find a path that I was confident in, so I just used a super-simple approach in CSS and a few lines of JS. There’s no native tab elements in HTML and I get the feeling that all these libraries are so simple as to be almost not worth using, so I’m not feeling too bad about this.

Some questions around behaviour here too - when the tabbed component stretches horizontally, do the tabs space or grow (some proportional combination might be possible with grid, but I want to avoid that for compatibility purposes).

Similarly, the content: does each column have a max-width? does it sit centrally or in a space-between flexbox way? Again, some combination would probably be ideal.

Stage 3 - content columns

With the tabbing sorted (more or less - I need to figure out how to have tab 1 open on pageload, but I’ll do that later) I got onto the atomic elements.

I won’t give a blow-by-blow account of this, but it’s trickier than you’d expect, especially when you can’t reach for flexbox at every stage.

I ended up using display properties like inline-block and inline-flex that I’m not too familiar with and having to contend with strange behaviour like the icons re-sizing and things being oddly spaced. There are odd defaults that kick in when you combine inline and block elements with flex which mean you need to explicitly state properties that you don’t normally need to worry about.

Also quite fiddly to get things changing alignment correctly as observed in planning. I got there.

log

This is where I’m currently at. The first product card’s contents are all (almost) per design - I just need to tweak the margins and whatnot.

objectives for today are:

~~finish spacing on card 1~~
~~add icons to tabs~~
~~add content for cards 2 and 3~~

15:28

OK, so that’s done, but I ran into a few problems and need to consult.

design system/component proposals

There’s a category of text of that I’ve been aware of for a while which consistently causes problems:

When text of very different sizes has to be combined - typically in this small-print or disambiguation role - the default margins, padding, line-height etc are too big and have to be stripped away.

In this example, I’ve made a new class (lazily entitled big-pink-text) and I’ve had to remove all margins and set the height of the element itself to enable me to get the text underneath close enough.

So when I get the additional cards and I have to add “from” in front of the price in one product in a significantly smaller font, I look at what I already have in the component that I can re-use. additional-info is the right size, but wrong color, so I append the .primary utility class to turn it pink.

Done, right? Nope because margins. Gah! so I’m going to end up making this specific style for a one-word span.

Anyway

I had a call with the designer and it was a big help. He understood my points and we made some good progress.

Turns out his preference is for fewer rules too, so we can prefer behaviour that’s closer to the old-skool flow rules and I was right in thinking that I was falsely attributing to him design concerns that he doesn’t have, like being averse to long lines, dangling words, etc.

Consistent with the react projects, we will try to avoid arbitrarily max-widthing components, preferring to define flow behaviours and letting the context/layout impose the constraints.

It was a big conversation so I can’t capture all the nuance here. Going to call it a day.

END

coming back to typescript

2019-02-25T02:34:00.002-08:00

2019-02-22-typescript

One of the hardest things I dealt with the last time I worked on this code base was Typescript, and that’s still the case. It’s like a difficulty multiplier that just seems exponentially more trouble than it’s worth.

My approach to such things has always been to prefer learning something after I’d suffered from the problems that thing was invented to solve. My side projects have never reached a point of complexity that I’ve lost track of the types, or experienced bugs as a result of mis-typing (or type coercion).

I say that, but actually I can think of a couple of recent examples where I was 1) expecting a primitive value to be returned by a JS method (interactionObserver if you’re interested) and 2) expecting a handlebars partial parameter to be treated as a boolean (production="false") when, because it was a non-zero-length string, was evaluated as true.

Anyway, the point I want to record - ahead of a proper investigation into typescript - is that in my ever-so-slight experience of Java, I’ve had to get used to specifying not just the type of a variable when I declare it

number, float, color etc.

but also, typing the return value of a function when it’s defined.

Hence void when no return value is expected.

So what do you do when a variable is being assigned a function? or a function returns another function? or a variable is being assigned to a function that returns another function? or a variable being assigned to a function that returns an object whose properties may be functions that return functions?

This is where I’m at, I think; react and styled-components are functions returning functions returning functions.

react re-acquaintence

2019-02-22T15:44:00.002-08:00

2019-02-22-log

I ended up doing a bit more more work on the react project last night before bed… and then a bit more after bed when the baby woke me up and I couldn’t get back.

I ended up with something very close to the designs:

But not close enough to pass muster - and not done in a way that’s particularly clean or in keeping with the project structure I think.

Observations

Very weird experience dealing with this stuff again.

It’s not that hard to get things rolling, but it feels harder than it ought to be.

the atomic design approach militates for consistency and reuse
component-based approaches militate for consistency and reuse
when designs are inconsistent you either have to handle the variance or duplicate code

I’m not able to comprehensively describe what I’m trying to say, but there’s a fundamental tension between what we’re doing and the facilities we’re setting up to do it. We’re optimising within the wrong parameters… or something.

Collaboration

Anyway, had a call with E and confirmed a lot of this. As long as I’ve understood the problems correctly, that’s OK with me!

Also got some pragmatic advice about the creation and deletion of components, so I don’t feel so uptight about that.

The whole process is fascinating to me. It seems so straightforward but it’s so, so hard.

Talked to AC and agreed that naming UI components in the design stages would help.

Back to react

OK, so I’m supposed to be creating a new atom for this box.

I guess I’ll call it DialogBox same as before. Rather than adapt the existing consent checkbox, I’ll start from scratch.

first I need to figure out where this stuff is implemented so I can insert my own component.
Layout is a presentational component which has the children I’m concerned with. I can remove all the children of layout without messing up any templates. that’s in templates/employee/adb/subscription.tsx

That template is the The Page I’m changing, so I guess it’s OK to do that. I comment out stuff within Layout and the progress bar and coin bit disappears - why?

OK, they’re not there in the original journey. Fine.

questions

Q: should it be a molecule?

A: yes, basically

Are we splitting these things down in terms of unit-ness (for want of a better term), or composition from existing HTML elements?

I don’t think my DialogBox is so simple as to warrant being called an atom, and my colleague agreed. The fact that, apart from being assessed on its own merits, it can contain child elements like <Button> sort of makes the case.

Ability to be implemented without regard to context also seemed like a relevant criterion.

Q: how do we control the width of the box?

FullWidthLayout is too wide. I would set the DialogBoxWrapper to max-width: 80px; if it was left to me.

The previous explanation I’d heard was that atoms (answer above notwithstanding), ought not to be hard-coded with width/height and other ‘primary’ (in my sense) values.

If I respect that, then what’s to become of this component that’s too wide? Is it OK to add a max-width? No, not really, we concluded. If we were going to do that we should pass it as a prop, and then the whole notion of layouts starts to be undermined.

Alright. So what suffers is design fidelity, in this trade-off. That’s fine. It might even feed back into the design aspects of the development cycle.

Q: husky complains about `px` unit. Do I need to use `rem` for everything? `em`?

A: Yes. rem. Make awkward pixel values awkward. I’m cool with that.

Q: I’m naming things in a BEM-ish kind of way. Is that objectionable?

A: Nope. We shouldn’t be too prescriptive about naming. If it’s not causing problems, it’s OK, and my naming scheme is coherent with the existing codebase.

I’ll bump some of the additional conversation forward into subsequent posts.

END

daily log - gulp, ghost, react

2019-02-22T01:43:00.002-08:00

2019-02-21-log

I’ve reported three things to do today:

Continue trying to resolve GA non-firing issue
Try out a couple more ways of varying data per environment in the website
Update local builds of signup, api and B2B projects, have a go at a fontend ticket for signup.

The first I will help with on request, so I’ll ignore that for now.

I’ll do a bit in the env stuff now since it seems tantilisingly solvable.

log

environment switching

10:13

Right now I’m checking if there’s some kind of global value that could be consulted that would enable the subbing in of a whole {{partial}} containing either the dev or prod code. I’d leave prod in as the default, actually and seek only to interpolate dev as required.

Options:

a js variable injected into the site via the portal, like const developmentInstance = true;
an @site value as mentioned in the link above
a helper that reads the current URL?

Attempt 1

I blanked the site title in the admin portal and used {{#if}} {{else}} and {{#unless}} helpers to try to conditionally swap tags… no dice. I wonder if it still resolves to true.

I tried putting some random text in as the site title to see if that would resolve to an (obviously invalid) analytics tag… it didn’t. But that made me realise the tag information isn’t coming from where I thought it was. :O