Making Github’s File List Responsive
Github is a place where a lot of us developers store our work. Many of us use it constantly as part of our workflow.
The smart developers at Github realize that users should be able to access the app regardless of device context. That’s why it works on devices from the size of your palm to the size of your desktop.
At a closer look, Github seems to be serving a different set of user interface (UI) architecture based on the device of which it’s being loaded. After changing the user agent to an iPhone browser, I see that the UI is responsive.
It doesn’t seem fully featured, but perhaps it’s the sign of a slow gradient towards fully responsive UI architecture for Github! Huzzah!
I’m sure there are many valid reasons for why it is the way it is at the moment.
In the meantime, I thought it would be a good exercise in making one of their components responsive. I figure I would start with a their file list.
But first, I want to respect the developers and designers that created this work I’m contributing to. Here are some centering assumptions.
CENTERING ASSUMPTIONS
- I believe all of the user interface engineers and designers that made these interfaces are intelligent and great at what they do.
- I believe that the teams have made the best possible design choices considering the app as a whole, as well as ALL of the concessions that come with it. I acknowledge the immense amount of factors that I am not seeing.
- I am doing this as an exercise in my own enthusiasm over responsive user interfaces. I live with the conviction that responsive user interface is not only a great solution, but should be the standard in web design.
- I am only working with a single component, and I acknowledge that I’m developing in a vacuum. Out in the wild, not only should components be responsive, they should work well with the components surrounding them.
- Good responsive design is not just about making one component responsive, it’s about zooming way out and seeing the web application’s context as a whole. That being said, one component at a time is a good start to the conversation.
- Oh, and I’m using ReactJS and PostCSS with SuitCSS components.
Agreed? Great.
Separating It All Out
So to start off, I usually begin by sectioning off pieces of the design. I’m looking for repeatable patterns that I can turn into components.
I like the SUIT CSS naming convention, so I went ahead and started giving each potential component a CSS class.
I hit three birds with one stone doing this because it allows me to:
- Separate out parts of the structure into reusable components.
- See how the UI architecture fits together as a whole.
- Choose consistent class naming conventions. (Which is vital for maintainability and organization)
I also like to draw it out by hand as a shell so I can make sure I’m focusing solely on the content of the component.
Having a content first mindset makes sure that we’re focusing on the function and content of the component rather than the cosmetics. It frees us to be less prescriptive with our UI solutions.
Here’s What I Came Up With
BAM. It’s responsive component. Ready for content to be plugged in.
Sickening no?
The Breakdown
.FileListHeader
Content: user avatar, username, version, latest commit number, and latest commit date
The avatar, username and and version number were not hindering the responsiveness of the content.
I will focus on the latest commit and the latest commit date.
All of the content is on one line, which is great if there is always plenty of space between the content on the left and the content on the right.
What happens as the viewport gets smaller is that content crashes into each other. Designers also have a tendency to truncate content with ellipsis when they establish a one line design metaphor.
My version separates the commit number and the date into two lines:
It’s important to note that it’s not good to just turn this section into a line that collapses when there is less room.
We need to clump the relevant pieces of content together:
- All the words that explain the latest commit number
- All the words that explain the latest commit date
Otherwise, we’ll have weird orphaning of words that won’t read well.
Example:
Latest commit: 2345938 37
minutes ago
Even with the monospaced number making it look visually different, it’s still no good.
.FileListItem
Content: filetype icon, file/folder name, latest commit message, last commit date
Github is sticking with their one line design choice because they’ve established it with their other components. With one line designs, I find that it gets exceedingly difficult for content to have breathing room as viewports get smaller.
Everything looks great in one line, until it doesn’t.
For example, if we were on a smaller screen, or the commit was longer, there’s not a lot of place for it to go. The text is arbitrarily put in the second quarter of the box, and either will be truncated with an ellipses, or have the lines break into paragraphs.
Following its content, I decided to clump the file/folder name and the commit message and stack them on the left side.
I feel that the color and the font difference is clear enough that it doesn’t cause extra mental load for the brain to differentiate between the two, even as a long list of files.
I do acknowledge that the date is now a bit separate to the rest of the content, but I find that it’s a secondary piece of information that the reader doesn’t immediately need to know.
With this set up, the commit message can be as long as it wants. Of course, for this interface to be successful, some reasonable limits should be placed.
I know that there’s all this conversation on what the ideal commit length should be. Let’s pretend that it was decided with the team, and it’ll be truncated on the back end.
Either way, it’s good to know that no matter the chosen character length, the UI will be able to accommodate the content.
Summary
That’s really it y’all.
A lot of turning a non-responsive component into responsive one is all about breaking down the content and distilling it to its most basic functions.
I hope that my process can help you make even more mindful choices about user interface.
Find me on Twitter and Instagram.
Emotionally Intelligent Front-End Web Development
I specialize in HTML, CSS, and ReactJS to help teams build responsive, modular and semantic web components for the modern browser.
Wanna work together? See what I’m all about at rvmendoza.com
Header image icon credit: Responsive Design by Kiran Joseph from the Noun Project
