How a chrome extension evolved to a web app
It started from a complaint.
“It’s really time consuming to pick the package name!”
Said when our engineers have to use another website to pick the package name in order to download the file.
When you have 1669 options (and expanding) in one select, you have a problem.
Version 1: Chrome Extension
Well it’s other’s website, we cannot just ask them to change the interface. But since it’s a web page, I figured we could just alter the page. So I built a Chrome extension. After several iterations, I added other features such as type to search function and auto populate the download text (“click to fill sn”):
Version 2: Web App
The chrome extension is used to ease the process of downloading files from another website. However, I found that engineers also used Excel to manage those downloads, along with other information about different downloads. Then I was thinking:
Wouldn’t be better if we can manage everything in one place?
Thus I built CMServer, a web app that helps engineers manage the resources and download/upload files.
I interviewed all related users/engineers, collected notes, and wrote user cases.
User Case Driven
I use user cases to help to prepare the requirements, and use it as a way to validate the design and the implementation.
Initially the list of PakGroups is displayed in “full” view, later I designed a “compact” view:
I thought the “compact” view might be a better option but I’m not that sure. So I collected the data of how many times user clicked each view, and it turned out the “compact” view won.
I was happy about it not because the design won, but because the decision was totally based on the users’ behavior.
Convenient Help Tools
Smart Defaults and “More” Button
Always Provide Tooltip
Type to Search in Select Control When More Than 10 Options
Use Placeholder for Examples
However, a recent read suggests this might not be the best option. I’ll investigate.
Documentation Is Important Too
- The CMServer is built with Meteor and MongoDB, it also uses some node packages such as Request for making HTTP calls and Cheerio for server side scraping
- It’s totally written in CoffeeScript
- I used common services such as MailChimp, Loggly, Kadira, and Mixpanel
- Initially it’s hosted in a spare Mac Mini (2009) on my desk
- I also created a Hubot for fun:
The first commit was in May 2014, at that time Meteor was in v0.8.
Higher Level Thinking
In CMServer I use the concept of “PakGroup” instead of individual files. It’s true that our engineers want to download files, but in another sense, they are managing something that’s more than files. By providing a higher level concept, it’s natural for them to manage, and at the same time it’s easy for programmer to code. I feel like I found the “right” abstraction.
Design Is An Iterative Process
Design is about solving problems. Problems could be changed during the time so the design needs to evolve. It’s an iterative process, there is never a “done” design.
Take CMServer for example, as you can see in the current version, it has the ability to queue the downloads. Initially CMServer is built to ease the pain of downloading files, so no one thinks about queueing downloads at all. Only when the downloading problem is solved, customers start to ask better experience: “Can we queue the downloads so we don’t need to wait and click?”
Simplicity != Simple UI/UX
“Simplicity” doesn’t always mean simple UI:
While this UI is simple and minimal, it’s very hard to use when it has 1669 options in it. I wrote a note on how I think about simplicity:
One More Thing
CMServer is a part of our Configuration Management system. The system also includes a desktop program (also written in web technologies). To find out more, please see this portfolio:
This is a part of my portfolio showcase on medium. To see the overview of my portfolio, please click here.