shields
shields copied to clipboard
badges
User Experience Design
:clipboard: Description
I popped into shields.io recently to make a badge and at first glance, I had zero idea what I was looking at. It was my first time using this service. While the site is technical and straight to the waffles, I felt there could be an improvement on the frontend.
🏄🏽♀️ I scanned through past issues (research, I believe) to see if previous concerns have been earlier raised. I was able to identify a few discussions that hinge on enhancing the current interface.
Let me list a tiny number of them here:
- https://github.com/badges/shields/pull/1163#issue-265025516
- https://github.com/badges/shields/issues/843#issue-196938870
- https://github.com/badges/shields/issues/2496#issue-389114635
- https://github.com/badges/shields/issues/777#issue-172880880
- https://github.com/badges/shields/issues/7176#issue-1030683469
- https://github.com/badges/shields/discussions/7129#discussion-3616401
- https://github.com/badges/shields/issues/1899#issue-349718225
- https://github.com/badges/shields/pull/1070#issue-255100790
User Research
I would love to contribute to shields by improving the user experience. This will involve:
- Usability Audit
- User research
- Ultimately, a redesign of the interface
Glad to hear you're interested in helping, that's fantastic news! As you've probably gathered from discussions and issues you've read, it's a widely shared opinion and goal amongst the maintainer team and all signs point to the community feeling the same. The biggest roadblock to making significant progress really has been the dearth of extra bandwidth amongst ourselves, and a lack of volunteers (so far) from the community to really push on the bigger pieces, so any assistance is greatly appreciated.
While I do absolutely agree that a refresh of the site is needed, I also want to stress the importance of keeping things framed in terms of our goals and audience.
At the end of the day, our service is functionally a static content generator/provider/host that's targeted explicitly at developers/technologists. The Shields.io site has largely, in my opinion, simply provided a lightweight catalog to our service designed to help our users figure out the url path for their desired static content so that they can then embed it somewhere (e.g. a markdown file).
I mention this because IMO it's very important for our site/catalog to remain focused on that user persona with a clean, simple experience. I wouldn't want to see a Shields.io site try to cater to other personas and get too noisy and busy; I don't think we want to be in the markdown-101 business, so I don't think our site needs to explain basics like adding images to markdown files (even though we do get those types of questions from time to time).
I'd also really like to avoid an unnecessarily complex or feature rich frontend that increases complexity in terms of things like source code management and dependency tree complexities (the latter is already problem enough)
Hey @calebcartwright! Massive thanks for hitting this stuff right on the head. I really do not know what to say right now. But hear this, from your response around personas I can say you've got a Blazin knowledge about UX design and I'm glad this conversation would be fruitful.
I dig your concerns about keeping the project lean and tight. No unnecessary complexity. Well noted. Markdown-101 business 🤣
I noticed in #1899 someone started on the redesign, are these the reasons why it wasn't implemented?
I think we can all acknowledge the front page of shields.io is in need of improvement. One of the reasons nothing is happening on this is time, but also the skillset of the core team is orientated towards back end dev and devops expertise. I don't think its controversial to say there is not anyone in the group of active maintainers who is a great frontend dev or designer.
In general I think you've done a pretty good job of picking out a selection of relevant issues but it is probably worthwhile a bit more of a trawl through https://github.com/badges/shields/issues?q=is%3Aissue+is%3Aopen+label%3Afrontend there are a variety of smaller issues with that tag which highlight paper cuts and usability problems with the current design and information architecture. From a user research perspective there is already something of a body of evidence there.
I noticed in #1899 someone started on the redesign, are these the reasons why it wasn't implemented?
As you've noted, there have been a number of times where someone has popped up and offered to do some design work and it hasn't really come to fruition. Its difficult to say exactly why this is. I think there are several possible things that might have contributed:
- It looks simple because it is one page, but there is more stuff going on in the frontend than it probably first appears. Its a deceptively large job.
- The current frontend code is not super-easy to work on. We've put a lot of work into the docs/code structure/dev experience around contributing service badges as this is by far the most common code contribution and pretty much always the entry point for a new contributor, but it is not really there for the frontend. Its harder to get started.
- Although everyone on the core team agrees the frontend needs improvement, none of us really have a clear vision of what an improved version looks like so maybe we aren't able to offer great guidance/feedback.
Happy to try and alleviate some of those as far as possible.
I'd also really like to avoid an unnecessarily complex or feature rich frontend that increases complexity in terms of things like source code management and dependency tree complexities (the latter is already problem enough)
Yes. The current frontend is trapped in a gatsby/typescript hellscape. In general, I think it is probably sensible to approach this design-first rather than tech-first but when(if) we get to the stage of implementing a design, there is an opportunity to review and simplify the tech at the same time, approaching it from the angle of trying to keep the maintenance overhead low.
I don't think its controversial to say there is not anyone in the group of active maintainers who is a great frontend dev or designer.
I won't speak for anyone else, but readily confirm I'm a quite terrible frontend dev :rofl:
@chris48s I gotta say this, I love the way you've articulated the throbbing issues and things-to-take-note-of.
I don't think it's controversial to say there is not anyone in the group of active maintainers who is a great frontend dev or designer.
🤣 About the designer part, that's not new to open source (I think). It's a common itch I've begun to see most open source projects are having a tough day scratching. That's why I'm advocating for designers into open source and stuff. I started my product design journey recently and would love an opportunity to work on something that literally saves lives...or could
The current frontend is trapped in a gatsby/typescript hellscape.
Ouuuf! That's hot.
In general, I think it is probably sensible to approach this design-first rather than tech-first but when(if) we get to the stage of implementing a design, there is an opportunity to review and simplify the tech at the same time, approaching it from the angle of trying to keep the maintenance overhead low.
Keywords: ** design-first rather than tech-first** I'm with you.
Actionable steps from here; I think I'd just do that trawling you spoke of and attempt to condense all that information into good stuff that we can actually use (now, or later)
📯 And It begins. Artemis.
Here is a decision I've taken after a brief moment of indecision - tracking the whole process with Miro. As this progressively unfolds, I'd greatly appreciate inputs and feedback. Please request for edit permissions on Miro.
Hey, just felt like I should chime in for my part here. I’ve had very minimal time to contribute to Shields over the last couple years. (Basically I try to show up for our ops meeting!) However I am interested in resuming work on the Shields frontend.
FWIW I work on frontends in my professional life, and have good skills in UX and wireframing, though not visual design. A frontend redesign of Shields is probably the biggest thing on my “o that I had the time” project wishlist. I’ve pitched it to a few friends who were looking to work with on their design portfolios. I’ve tried to engage with outside contributors on it too, though agree with Chris that it’s generally been hard to connect.
It looks simple because it is one page, but there is more stuff going on in the frontend than it probably first appears. Its a deceptively large job.
Agree with this.
The current frontend code is not super-easy to work on. We've put a lot of work into the docs/code structure/dev experience around contributing service badges as this is by far the most common code contribution and pretty much always the entry point for a new contributor, but it is not really there for the frontend. Its harder to get started.
For a mid- to senior-level frontend developer, I don’t think the stack would be a major barrier to entry. React is the most popular frontend framework and TypeScript is very popular too. (I do think we should replace Gatsby… though probably all these questions about the frontend stack are for a separate discussion.)
Although everyone on the core team agrees the frontend needs improvement, none of us really have a clear vision of what an improved version looks like so maybe we aren't able to offer great guidance/feedback.
I’d frame this a little differently by saying we don’t have a workable design process, where people can propose changes and get approval on them prior to code-review time. IMO this lack of process, even more than any technical barrier, make it hard for an experienced frontend developer to plug in without a lot of existing context on Shields. In addition, being effective at making UX changes requires a great deal of collaborative bandwidth with the core team. (And I have had almost no time.)
In that light, I think there are three main methods of getting into this work:
- Focus on incremental usability improvements.
- A developer could start on one of the open frontend issues.
- A designer could, as @kohasummons suggested, conduct a UX audit. This could involve identifying new issues and ranking them alongside the existing issues which have been discussed.
- Create a process for proposing and reviewing designs for the Shields team and other community members to implement. Initially these probably should be small and focused, and then we can take on larger proposals over time.
- Independently from the Shields team + site, create new, independent frontends which consume the Shields badge data. Through these experiments, play around with new ideas and get feedback from the community about what they like.
@kohasummons You mentioned starting with a UX audit and I think that's a great idea. What do you think about starting your work there? You could identify what you think are the biggest UX issues, combine your list with the open frontend issues/bugs/suggestions, and then try to reason about the priorities.
Honestly what you wrote in your top post:
… at first glance, I had zero idea what I was looking at. It was my first time using this service.
… might reasonably be described as the biggest problem, at least for a certain user persona.
(Have requested edit access on Miro)
I also meant to add that while I'm :100: open to using any additional tools for the truly visual aspects of this, I've got some reservations about anything that bifurcates the enumeration and status tracking of work to a different tool.
My preference would be to keep work in GitHub as much as possible
What if the landing page was just this :wink:
So I hear you want to make a badge?
For a mid- to senior-level frontend developer, I don’t think the stack would be a major barrier to entry. React is the most popular frontend framework and TypeScript is very popular too.
I think you're right that contributing isn't difficult because we are using some exotic or unusual tech. I was thinking more about the stuff around that like docs and code structure. The onboarding experience if you want to contribute a service badge is pretty good IMO. For the frontend there is a lot less to go on.
https://www.figma.com/file/6w9sI3u2LPm4XlNhJ2axtW/Shields.io?node-id=501%3A8601
@chris48s @paulmelnikow @calebcartwright @znarf, You could poke around in explorations to see where I'm taking this. 🤾🏽
Hi. Thanks for continuing to work on this. I have seen it. I did have a look at the mockups and have scribbled some quick notes.
I haven't managed to find the time to write that up into something intelligible. In general I'm struggling to find loads of time for this project/open source as a whole right now. I'm going to try and slot in some time for it in but it will probably be next week.
Hello. That would be awesome. Can't wait to hear what you think already. There are a few things i noticed are common among other open source projects like sponsor tiers for example. I don't know if we even have a structure for stuffs like that. So yes, what ever feedback you can offer now would greatly make my decision making process less painful.
There are a few things i noticed are common among other open source projects like sponsor tiers for example. I don't know if we even have a structure for stuffs like that.
Let me know if I've misunderstood you, but we are actually already set up on OpenCollective (https://opencollective.com/shields) for people to make donations.
The donations we receive through OpenCollective mostly cover the operational/infrastructure costs of running the service (more or less), but that's really separate from maintainer bandwidth. Even if any of us wanted Shields to be our day job that paid the bills we need to live, the level of donations is nowhere close to what it would need to be for even one person to get by :smile: Other programs, like GitHub Sponsors, don't fundamentally change that calculus, and can actually add a lot of overhead and work for the person due to tax liabilities in many jurisdictions.
As such, like most projects, we're all operating on a strictly volunteer basis when and as we can, and the amount of time just ebbs and flows depending on work, other things going in life, etc. That's part of why we haven't made much progress on this front, and why it's great when folks like yourself are eager to pitch in and assist!
@calebcartwright No. No. You haven't. I'm taking a truck load of cues/inspiration from the vue project. They have this sort of "sponsor tiers". So there is Bronze sponsor, gold sponsor. I feel this are incentives to motivate donation.
Check it out: https://opencollective.com/vuejs
Just saying. 🛸
No. No. You haven't. I'm taking a truck load of cues/inspiration from the vue project. They have this sort of "sponsor tiers". So there is Bronze sponsor, gold sponsor. I feel this are incentives to motivate donation.
Thanks for clarifying and sharing. While funding and sponsorship just about always make for interesting dialog, I feel like it's also fair to say that it's orthogonal to the thrust of the issue, and as such I'd like to suggest that we keep discussion focused on the topic of this issue around the frontend design.
(I realize you're exploring incorporating sponsorship information into the UI, but I still think the specifics are off topic)
https://www.figma.com/file/6w9sI3u2LPm4XlNhJ2axtW/Shields.io?node-id=501%3A8601
@chris48s @paulmelnikow @calebcartwright @znarf, You could poke around in explorations to see where I'm taking this. 🤾🏽
It took me a while to realize there were other wireframes scattered around :sweat_smile:
Aesthetically it looks nice, and very well done! It definitely evokes more of a "modern" feel for me.
Feel free to correct me, but I interpret the relative placement of pages/screens to connote a progressive call/path a user would take. One concern I'd have, if that's indeed a correct understanding, is that I feel like we're increasing the mandatory click-depth required by at least 1 in order for users to get to the area that drives 99% of our users to the site.
Fundamentally, our site is about enumerating our catalog of badges and providing aid to users that need to construct their badge url. The landing page you've proposed strikes me as more of a stereotypical product overview/branding/marketing page that I don't personally think is necessary, or at least which shouldn't be front and center. I.e. we're not trying to convince people to buy our product or service, so I don't think it's important that essentially the first thing people see is big-name projects/companies that user our service, and certainly not at the expense of adding a click (ostensibly the Create badge button) in order to utilize the core functionality of the site.
As for the badge factory page, it similarly looks really nice, but I'm curious what the experience would be like on smaller screens given the page layout? Would users end up having to do a lot of vertical scrolling (e.g. we have just about 1,000 services, or "projects" as you labeled them which would be enumerated)
At this stage, I don't think bikeshedding exact design details (colour schemes, logos, etc) is the most important thing to focus on so I'm mostly going to steer clear of that. One of the things that reviewing these wireframes is forcing us to do is really think about and express clearly what use-case we are trying to serve and the information architecture. That may be one of the most valuable things you are helping us to do.
I'll also note that I've been working on this in parallel to @calebcartwright 's comments so there's a certain amount of duplication here (good sign that these points are important). I'm just going to post it all anyway.
Shields - Home
I think the first big thing I'd challenge is dominating the home page with featured sponsors and donation asks. We do currently have a page for acknowledging and thanking sponsors. https://shields.io/community At the moment it is tucked away in the footer. We should make more of this than we currently do but it shouldn't occupy most of the real-estate on the front page. The most critical user need we want to service here is "I want to put badges in my README". Fundraising is a secondary goal. Any re-design should keep the core "product" (for want of a better word) up front and centre. I'd also assume that we will continue to as far as possible outsource keeping track of who is/isn't sponsoring us to the OpenCollective auto-generated SVGs for this in preference to taking on the maintenance of this ourselves. Maybe the other thing we could consider devoting some real-estate to on the landing page of shields.io are:
- More clearly communicating to a new user who is not already familiar with shields "what is this thing?" / "how does it work?" / "why do you care about it?".
- Talking about (or at least linking to) the other things we do ( badge-maker NPM library and shields specification )
In general, I don't think using the VueJS site as a template or inspiration point is a great match. Vue JS is a library. Shields.io is (primarily) a web service. The role of the website is a bit different.
I think we can also ditch the graphics with badges overlapping text and at an angle, but as I say, I don't think this is the most important place to focus at this stage.
Shields - Badge Factory
My interpretation of your "badge factory" screenshot is that what we're looking at there is a "modal" with the inputs on it, but the badge preview on the "page" behind it? Is that right? We don't collect any stats on visitors to the site (intentionally, and we don't plan to). I suspect we skew more towards desktop than a lot of sites but I think one of the (many) problems with our existing design is the UX on mobile/tablet and if my interpretation of your design is right we'd be looking at replicating some of those problems. I think if we're looking at a redesign we should probably be moving towards something that looks like a "page" (may not actually be implemented as a page if we end up with another SPA - lets abstract that for now) for each builder rather than a modal popup. I think we'd also want to think about what any design would look like in a mobile view.
One of the leaps we've made here is assuming we will associate an icon or logo with each service family. I can't find a link to the issue, but this is something that has come up before and we've decided against it. Assume for the purposes of front-end design we won't be doing this. Probably the two most important considerations here are:
- Badges should be informational rather than promotional
- There is maintenance overhead associated with this which we don't want to take on.
but there are others. In general I think we should be aiming towards something that is cleaner and more visually appealing than what we currently have but which is fundamentally text based (rather than icon-heavy).
The hierarchical left-hand menu you've proposed looks like it would work ok for services (you've labelled them "Project" but we call them "services") that only include a few badges but we have over 40 different github badges and for the categories view our largest category is version badges. We have over 100 version badges. We need to think about a design that will scale well enough to allow a user to easily browse long lists here. Another common pattern is subtly different variations of the same thing with long descriptions e.g:
- Docker Image Version (latest by date)
- Docker Image Version (latest semver)
- Docker Image Version (tag latest semver)
or
- Libraries.io dependency status for latest release
- Libraries.io dependency status for specific release
- Libraries.io dependency status for latest release, scoped npm package
- Libraries.io dependency status for specific release, scoped npm package
- Libraries.io dependency status for GitHub repo
A design that allows the user to read the whole text (rather than truncating) is also going to be quite important. Maybe we could reduce the need for some of this with a better builder UI, but some of this will be unavoidable.
"show me around" is an interesting idea, but for now it is just a link title. I'd be interested in what you'd envisage that being (text description is fine - doesn't need to be a wireframe). I'd have a couple of competing ideas, but also this feels like an ambitious stretch goal. Focussing on improving what we've got in a simple and maintainable way seems like the first step rather than imaging ambitious new features.
How do you see "Docs" or "API" as being different to the badge builder? (for shields.io the URL schema is the API)
In general, the badge builder is there to assist the user in constructing a URL not hide it (remember: the target audience for this is developers, and the URL schema is the API), so we really want to keep the terminology consistent (e.g: the param is &logo= - lets not present it as "Icon" in the UI) and expose it explicitly everywhere. I'm not saying this is exactly what we should aim for, but one of the things badgen.net 's builder ( https://badgen.net/builder ) conceptually gets right IMO is that the task is very explicitly framed as helping the user to construct a URL , not abstracting it.
When it comes to logos, SimpleIcons has over 2,000 icons and is growing. A drop-down with >2,000 things in it is too many things for a drop-down. Auto-complete would be nice. MVP is leave it as text but improve the documentation here on how to find the slug.
Have you had any thoughts on how to present:
- static badge
- available named colours (esp semantic aliases)
- endpoint badge
- dynamic badges (json/xml/yaml)
- globally available params?
?
Hi @calebcartwright @chris48s Thanks for weighing in on this. I read through the entire feedback and they have helped me understand the scope of the shields service to a much greater extent. In the same way, also exposed areas where I still need clarification.
I think having a conversation about the project generally, something like a call, would help. So, If anyone would want to have that call, I would greatly appreciate it.
Speaking strictly for myself and not the others. While I'm not necessarily opposed to having a more synchronous connection down the road, I'd prefer and recommend that we try to accomplish as much as possible asynchronously, and only fall back to something like a call if absolutely necessary.
I realize and readily acknowledge that there benefits to voice and synchronous discussion, but it's also one of the most time consuming, expensive, and logistically challenging communication mediums, particularly in the distributed+volunteer context of open source. We already have a lot of difficulty just trying to get a handful of the team together due to other obligations, time zones, etc. and I'm just not convinced that doing so for this topic will be practical nor would it be the best approach at this time.
We've got this issue and a dedicated chat thread, and I'd encourage leveraging those to ask clarifying questions and bouncing ideas.
Before jumping in on rereading the comments, I see two issue here.
1. There is no separate user stories
This one is pretty good, actually.
popped into shields.io recently to make a badge and at first glance, I had zero idea what I was looking at. It was my first time using this service.
Not sure it has a solution, but for establishing metrics of success it can be useful. Like recording bounce rate, first time on page. I know in the past shields.io claimed that it is no-tracking service. Not sure if anything changed since then.
2. It's not the first redesign
I remember the page was way more simple than it is now. Evaluating at least how it looked before can also help to see establish targets for A/B experiments.
When it comes to logos, SimpleIcons has over 2,000 icons and is growing. A drop-down with >2,000 things in it is too many things for a drop-down. Auto-complete would be nice. MVP is leave it as text but improve the documentation here on how to find the slug. (@chris48s https://github.com/badges/shields/issues/7815#issuecomment-1153272882)
We could use loading="lazy" for icons in the selector, with a search input. Like https://simpleicons.org does.
~~For React, we also can use https://github.com/bvaughn/react-virtualized for rendering a virtualized list.~~
Update:
The react-virtualized lacks maintenance now. We could use react-virtuoso instead.
I've been working on a proof-of-concept for a new shields frontend. There's some more links and notes on this over at https://github.com/badges/shields/issues/7982#issuecomment-1346871332 . While what I've done doesn't directly implement @kohasummons design, the conversation we've had around this has definitely fed into and influenced what I've done there.
@adsingh14 - we are tantalisingly close to deploying a new frontend (PR: https://github.com/badges/shields/pull/9014 ) Watch this space..
We have just launched a completely redesigned frontend https://shields.io/
While we did not directly implement the designs here, the work in this thread definitely helped and influenced the process. Thanks :heart: