Conversation
codemacabre
left a comment
There was a problem hiding this comment.
There are a couple of new classes introduced which aren't used anywhere:
.iati-footer-block__subtitle.iati-footer-block__content--divided
These should be removed unless actually intended for use, in which case, stories should be created which use them.
The new .iati-footer__section--mid class has flex grow to factors 3 and 2 for first and last child respectively. This is a weird way of producing a flexible layout without defining the number of columns and could easily make for accidental multiple columns. Plus, the 3:2 ratio doesn't quite line up with the newsletter column above, which makes the whole thing feel misaligned.
The border here (class .iati-footer-block--bordered) contributes to the misaligned feel; it doesn't align with any elements above or below and feels antithetical to the design of the footer in general. Better to remove it entirely, or at the very least, change it to a more muted colour than the light blue generally reserved for interactive items.
The HTML construction has more div elements than necessary; something which is an existing problem across the design system, and needing to be fixed at some point, but the trend is continued here.
The naming of the feedback list and items feels repetitive and confusing: The list itself is called "Feedback", the first items is "feedback and suggestions", yet "feedback" is repeated in the second translation item, which could be removed or replaced with a different word to prevent duplication and ease clarity. Cognitive accessibility is important in this respect.
One (of many) problems with submitting vibe-coded PRs is that PRs are meant to not only allow for code to be reviewed, but also to aid understanding across the team. This took longer than normal to review, made it difficult to understand why design and code decisions had been made and, and has now unfortunately been pushed to a 'changes needed' status which will involve either further vibe-coding or a rewrite by a human (which would have been more efficient in the first place).
|
Thanks for the thoughtful review, @codemacabre . All of the faults that you detail fundamentally arise from the limitations of my own knowledge and experience of front-end development. I was keen to try out something higher-fidelity than moving screenshots and text boxes around in Miro or Figma, so I've used Claude as an advanced form of copy/paste instead of trying to make all those nested divs work by hand. I made targeted prompts, reviewed the code at all stages, made manual edits where I did know exactly how to effect the change that I wanted to see, and in the process was able to try out a range of ideas to see what I preferred. In the spirit of information sharing, you may be interested to learn that I tried, and dismissed:
I had hoped that you might comment on the core of what I'm putting forward here: an overall approach to soliciting feedback in an unobtrusive way through the use of links in the footer, and doing so through the use of a piece of space that is underutilised in practice (either for content or as "white space"). If you think that this approach is fundamentally a reasonable one, then it makes sense to look further at the detail. I chose the 2:3 ratio despite it being misaligned with the newsletter because I thought it looked better in and of itself. The newsletter form isn't actually used anywhere (I think...); I'm thinking of removing it entirely as we can always get it back from the commit history if we do need it. It was intended for the IATI website, but that's not going to be using the IATI design system. It's caused some confusion when people come to use the design system - I've had to ask for it to be removed from implementations but never asked for it to be included. I tried a couple of colours for the vertical dividing line but ultimately landed on the same colour that's used for the horizontal divider in the footer as that seemed neater, to my eye. I'm happy to hear suggestions on which colour would be better. I tried a few variations of the phrasing for the links and the title, including a subtitle (which is why we ended up with those unused classes that I forgot to remove). I was trying to balance the cognitive load associated with the repeated word "feedback" against the principle that links should be independently descriptive. I'm happy to hear alternative wording suggestions, or I can work through the microcopy with Mollie at some point. I have no strong views as to whether we continue to proceed with the code already on this branch or start afresh. I haven't done any vibe-coding in this PR and I don't think it would be an appropriate technique to start to use to develop from here; if we do proceed with the code as-is then we can manually iterate. |
Yes, this is a perfectly good place to put a feedback link. I think the simplest method would be to include a single link to one place for receiving feedback, perhaps in the form of a link styled as a button to make it stand out, along with an icon if available. A header may not even be necessary. I am happy to mock up a couple of variations as a first step. |
|
Thanks @codemacabre ! Can we look at removing the Newsletter section alongside this? Either straight-up deleting it or moving it out of the default view of the footer. I don't think it makes sense to give ourselves the constraint to trying to make something look aligned with a component that just doesn't exist on our live websites. One thing to bear in mind is that, at the moment, some websites have some very long text in the Additional Information - the Dashboard, for instance. My idea with a divider was to try and bound that; could we include in the design system an example with more text there so that we can see what it looks like when the left-hand side is busier? I do like the button, but we'd need to work on the copy. Could we shoehorn the button into the very bottom of the footer so we don't need to have text saying to click the button? Or do we go big and add it to the button set at the top? Now that's come to mind, I'm tempted. I'm trying to figure out if I want to directly solicit translation feedback via the interface or just make it an option on the form. We've had issues with our existing approach and we're looking at a new one, and I'm conscious that there's a whole load of cultural issues around why people might not feel comfortable raising issues with translations unless directly invited to. Two buttons in the footer might work quite nicely for that: Product Feedback | Translation Feedback. |



@codemacabre I want to introduce the concept of a user feedback link on (almost) every page so that we can start to hear from people in their more day-to-day lives in IATI rather than just when they have an issue that they need to talk to us about.
I played around with some ideas via chat with Claude Code and this is where I got to. I don't love it, but it does fit the links that I need into a space that has previously been under-used.
Thoughts welcome - if this is an acceptable design and solution then please merge, or if you'd rather explore alternatives then do say and we can look at it in due course. I'm conscious that we're very short on your time in general and this unblocks other work so I'd be open to a merge-and-improve-later decision as well.