It’s no secret that I have become an enthusiastic member of the Ember community. With my deep love of web standards and separation of concerns, Ember itself just ended up being a good fit for me- and the fantastic community upgraded a good fit to a great fit. One of the places I noticed I could contribute was to the Ember website itself- especially where accessibility standards are concerned!
In this article, I’ll share my progress on an overhaul of Ember’s public websites, and maybe there will be some tips for managing changes to a long-lived open source project along the way.
Goals
With such an open-ended project, it was important to define goals:
- Improve the accessibility of the website (WCAG 2.0 AA standards)
- Implement responsive (device-agnostic) design
- Improving the CSS code by removing unused code and consolidating repeated code
- Do all of this while keeping the website functional and using the constraints of the current project
- Update/refresh the visual design
- Document a visual design styleguide, so maintaining and contributing is even easier in the future
- Use the documented styleguide to create components in both Ember (ember-styleguide) & Glimmer(glimmer-styleguide)
- Transform the website into an Ember app(and maybe some of the other apps into engines!)
- Add content that will be helpful to prospective users
Very ambitious! Good thing this is Ember.
Project Management
Right now, I’m using Github’s project feature to track the overall website project, which has been useful to help me easily get a big picture view and make sure I’m at least tracking all of the ideas for the website that come my way. Here’s a screenshot of that overview screen:
I like this method for a few reasons- I’ve used JIRA for a long time so this style of project management is familiar to me; Github has improved their projects feature and I like the automation of it. I can also spend time looking at this view and thinking about how I could break stories down into smaller stories, since we know that helps encourage new contributors.
The current process
- Ideas for improvements or changes go into a card in the inbox. These can be my ideas, or ideas that I hear about from the Ember core team, or even just ideas that people post in the #team-learning channel on the Ember Community Slack chat.
- Once I have given those ideas enough details for actual work to begin, I convert them into issues, assign them to the correct repository, and they automatically end up in the “to-do” column. I also try to give them good labels, so other people can contribute!
- If that issue needs to go into a different repository, I’ll start the issue in that repository, but still track it here, that way I can keep tabs on the overall progress in one place. This was an accidental discovery for me, but was a very useful find. Here’s what that looks like:
- I’ll move an into the “In-Progress” column once I’ve started working on it or I know someone else is working on it.
- Once an issue is closed or the code for that issue is merged, it is automatically moved to the “Done” column.
Creating a Styleguide
CodePen has been a really helpful tool for prototyping the styleguide. I can work out static designs and get feedback from other members of the learning team before implementation. It also allows me to make sure I’ve designed pieces that will work with the overall flow of the entire website. It also lends itself to discussion with the other members of the learning team- we can talk about a proposed element and make changes while we’re having the discussion. Here’s an example, using the call to action (CTA) components part:
It’s still a work in progress, so there are definitely ways for anyone to contribute- look for issues with the tag “design”.
Completed work
It’s been a bit of a recursive adventure to figure out not only what we wanted to do, but how best to approach it. The core website was built with Middleman – & I’ve never worked with Ruby before, so it’s been an adventure. On top of that, it took some detective work to figure out how to get it to build on a PC (my dev environment of choice). The guides, API, and builds app are all separate apps that are hooked into the core app- and I had to learn how all of those things fit together.
Here are some specific items that have been completed:
- figured out how to organize the project & wrote it down
- page layouts have been (mostly) normalized to use semantic HTML and correct ARIA-* roles where required.
- updated the color palette to at least pass WCAG 2.0 AA color contrast tests
- determined the site hierarchy and how we wanted to organize the pages in the navbar (both in the interim and long-term)
In-Progress Work
Right now, we’re working out the best way to integrate some of the design changes into the Guides and API apps. I’m also working on the navbar, because we’d like to have dropdowns and a better mobile navbar. We’re also working to finish the styleguide, so we can better support those who wish to contribute.
One new addition to the website is the “Why Ember” section, new content that will be added to help engineers and executives consider the reasons Ember might be a perfect choice for their next project. This is in active development & there is room for contributions. I think this part in particular will be a great community effort!
Planned Work
Here are some of the planned but not-yet-implemented items:
- convert the website to an Ember app
- break out the common parts into components (ember-styleguide)
- improve the site’s SEO
- improve the “Teams” page
- develop, document and implement process for the statusboard
How this affects the website
You may notice some changes as you continue to visit and use the website (“wait…this didn’t look like this yesterday…”). You might love the changes, but you might find something we missed, or something that doesn’t look quite right. If that happens, please report it as an issue. Thank you for your patience!
You can be a contributor too
There is also opportunity to become involved! Please come to the #team-learning channel on Slack, or check out any of the repositories I’ve mentioned in this post. There are multiple ways to contribute- project management, content (writing and editing), marketing, QA, design, and development. Everyone is welcome!
Note: Jen Weber reviewed this post for content and accuracy. Thank you, Jen!