Hi all I’m Amy, I’ve volunteered to help out on the AMY.BO website refresh. I’m a data scientist with a small bit of experience in UX and a very small bit of web dev experience.
I’ve started this thread to use for feedback throughout the process, which I expect to take a few months (I have limited time each month) - though if anyone else has UX/ web development experience, then it’d be great to work together on this if you’re looking to help out!
To kick off, I’ve created a very rough wireframe using Figma - this is not clickable, as I figured we could iterate that if needed and otherwise just try out in dev - so it’s just some static frames to explore (1) the site map and (2) page layout and format. I’m very much not a designer so feel free to ignore any elements straying into this.
I would love to get feedback on this in general, and in particular on
layout
branding (e.g. colours, typefaces)
site map
what belongs on the forum vs these pages
pages to prioritise for dev
Thanks in advance & looking forward to collaborating
github.com/amy-bo/branding now has most of our current work on branding. It would be great to know from the experts what we should add there, so the website and all other collateral can flow from a common source. And with that in mind, if anything there doesn’t make sense from a branding or sustainability perspective - please do let us know.
Everyone’s welcome to join our next meeting, feel free to vote on it here Calendly or if none of those times work for you please let me know.
And thanks for kicking this off @Amy - yes, it’s a huge improvement on our current site. And well done @gerrit for adding the first comments in Figma. I’m now struggling to see how I found it difficult…
Thanks everyone for feedback so far! And thanks Martin for the branding repo, very useful.
This week we’re having a catch up (see Martin’s post above) on the wireframe feedback, and from my side this will act as the kick off for starting dev on the astro-based site. The wireframe is mainly a jumping off point for this so I won’t develop it further, just take the feedback and work it in to the site as it’s developed. It would be great to have any more feedback submitted before then.
@Martin@gerrit, for our meeting this week, it’d be great to discuss:
the sitemap proposed in the wireframe & whether there’s anything missing
if there’s anything that seems really out of place
priority pages to develop first
timelines / next steps
Anything else you’d like to chat through? Would be useful to know ahead of time so I can prep. Thanks!
Thanks @Amy
On your first three points, I’m wondering - since the current site’s pages are all in MD for Hugo and the new site’s pages will all be MD for Astro - whether the first question is how we map all the current pages to the new site and whether any are so out of date that they would be better deleted?
If so, would the timelines / next steps be:
Agree page mapping - all at meeting, with proposals in advance.
Agree Astro theme (assuming we want to start with a pre-made Docs theme, these are the options, Starlight won the last time I checked) - all at meeting, with proposals in advance.
Set up Astro with theme and mapped pages - @Martin one week from agreement of the above.
Hi Martin, happy to chat through the above tomorrow. Broadly, I mapped the content that I thought was relevant from the existing site onto the new site in the wireframe, happy to talk a bit more about that if useful. Would be good to agree the astro template, I don’t have a view here, I would otherwise just default to the one that allows replication of the wireframe and adjustments as closely as possible.
Thanks Amy, if anyones able to find a template that better fits your wireframe, it would be great for us to have a look at that tomorrow. Failing that Starlight would get my vote as it’s what Astro use for their own docs, so we can be pretty sure it’s fully compatible and well maintained.
It must be said that some of my favourite bits of their docs aren’t vanilla Starlight, but I’d love it if we could determine how to implement them too - for example their ‘build a blog’ tutorial tracker and checklist. These blew my mind as they’re a way to run a fairly decent LMS through a static site, apparently just using user cookies to track progress, etc.
Since we last caught up, I’ve looked into starlight more. My thoughts below - happy for anyone to weigh in here.
Pros for Astro Starlight
easy to pick up, and the documentation is pretty good.
we can implement other components outside of starlight using Astro - so whenever starlight doesn’t work for us with css modifications, we can just build something with Astro Overriding Components | Starlight . [I need to understand this a little better - for instance, I’m trying to override the hero component so that we can have a full-width background image on the hero, but it’s not yet clear to me how to do this.]
Cons for Astro Starlight
There are fixed components that are features of starlight templates - so it’s pretty likely that there will be things we want to override fairly often. For instance, the nav bar header looks like it might need overriding if we want to include links to other parts of the site on the right hand side.
There are also things we’d like to do, e.g. include links in a footer, that don’t have a corresponding element in starlight by default. This requires creating additional elements outside the starlight template. I’ve not looked in to how difficult this is yet.
My conclusion for now is that I’m happy to pursue using starlight as it seems like we can fall back on Astro, and hack in other components if we need to without too much trouble, and with guidance on how to do this from the docs.
In terms of whether we can alter without breaking the starlight template updates, I think this isn’t really a concern - as long as starlight maintain the functionality for components to be overwritten, components that we write shouldn’t break the template. The concern would maybe be that this will just not necessarily update alongside other starlight-native elements.
Some questions
Is choosing Starlight now an irreversible decision (I’m thinking in terms of porting the site over)? If it seems irreversible from your POV @Martin then I will hold off committing for now until I’ve done some more development - otherwise, if we could choose this now and switch later if we needed, then any actions on your side for doing a starlight build and porting across.
Do we have any stock images similar to the ones in the wireframe, e.g. for forests, to create a homogenously coloured background (I chose the forests in the wireframe because they created a green backdrop similar to the branding green colour, on which text could show up regardless of where it was positioned on top).
I’ll use a repo on my own GitHub for the time being, just for the code whilst I dev and create locally, and before we can move across to the Amybo org. Are you happy for this to be a public repo, or would you prefer I kept it private for now?
I recommend that we use tailwind for styling - this will help to make the site accessible and I think more consistent as different people potentially pick up development in the future. I’ll presume that’s okay unless strong feelings on this?
I’ll continue to work on this over the summer - for community awareness, the pace I’m working on this is at about half a day a month, so if anyone else wants to get involved, let me know. One of the next actions is pushing to GitHub so once that’s done it can be truly collaborative.
I’ll try to quickly respond to your questions now, but will pop back soon and update my answers once I have had a little more time to respond. Let me know if anyone reads this, and I can let you know once I’ve updated it.
Starlight
Yes, I imagine we’d need to do the same with any other theme - in which case the question would be whether we buy a paid theme, that comes with an included level of developer support, or use a free one that likely has more limited community support. The nice thing about Starlight is that is (at least when I first researched) by far the most popular docs theme, and it’s built by Astro. Option three is to entirely build our own theme on vanilla Astro, but I imagine that’s making work for ourselves. I’d suggest you give it a go with stock-Starlight and whatever styling options it gives then we meet up and decide the to-do list in order to bring it close enough to the wireframe that we’re happy to go live. From there I can work on the content migration while you work on the design.
Is Theme Choice Irreversible?
From the content perspective, not in the slightest. Astro builds each page based on markdown files, so the content shouldn’t change at all if we pick a different theme. Starlight-specific styling may not translate, and any theme hacks we do probably won’t.
Stock Images
I think the earth image from the Banner would probably make most sense in place of the forrest. Let us know the optimal dimensions would be then @Laura can hopefully work up custom versions for you.
I’m hoping we can update this with original micrography and HOB hero images in due course, but I’m very much hoping the HOB won’t be green! Best guess is that they’ll be kind of #CC9944 to #DDCC66.
Public Dev Repo
Absolutely happy for it to be a public repo - feel free to share it here.
Tailwind
I don’t have the experience to weigh in on this, so if you & @gerrit are happy with Tailwind (and nobody else objects before we’re invested) I’m delighted. I think I recall that quite a few paid and free Astro themes use Tailwind.
I’m Amy, I’ve volunteered to help out on the AMY.BO website refresh. I’m a data scientist with a small bit of experience in UX and a very small bit of web dev experience.