Should I feel bad knowing that if I were project manager, I'd feel like someone wasted valuable time making the dashboard look so pretty? Am I an idiot just for assuming that was done in house?
Edit:
I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than 10 minutes of actual focus) and think to myself: "If that were me, I'd feel like I was just goofing off"
Get the information there. Make sure its nice and and usable. This does more than that though, which is great. I personally just would feel like I was wasting time and energy worrying about picking a color scheme when I had other work to be done.
Third thought:
I appreciate the romantic justifications mentioned in the replies. I think they're fairly superficial, but they are romantic, and thats fine. I think the real difference here (and the root of the disagreement) has to do with why I associate this with 'waste of time'. There is obviously opportunity cost of doing this. I expect people most in favor of this stuff are salaried and not really concerned with opportunity cost. If I were salaried, I wouldn't feel like I was doing something wrong by doing this work because I'd do in in addition to my other work. I'd stay late and do it because I enjoyed doing it. I don't have that luxury where there isn't much opportunity cost because I'm paid by the hour. I don't work over-time. I'm not going to spend an extra hour at work one day to take care of this, so if its going to get done, its going to have to be prioritized over my other work. If picking colors (however important it is) is the most important thing on my to-do list, I have a problem.
TLDR: I'm paid by the hour. Thats probably why I feel this way.
It was done in-house. We really care about how our graphs look, because graphs represent information. It's like typography. Humans learned how to write 5000 years ago, and it took us a very long while until we mastered the art of transmitting information like that. Once we mastered it, however, we started caring about the way we present that information. For no specific reason, but we developed unique typefaces that look beautiful, different, yet transmit the same information.
Likewise, we've spent a ton of valuable time graphing and mining data from all over our stack; it's only natural that after that, we care about how we present that data. Like typography, it's hard because it's an arduous hunt for the aesthetics hidden behind information. But this hunt is what makes us human.
That's why we design beautiful graphs, just like we'd design a beautiful typeface. Not because we are GitHubbers, nor because we are designers, but because we are humans.
Life is too short to stare at ugly graphs. And yes, you should feel bad.
This is something that coders should think about. A culture of quality drives looking for perfection at every level, whether it be code, typefaces, graphs, or network configuration.
Just 'cause there's non-code aspects doesn't mean they have freedom to be ugly when you're striving for excellence.
I don't think its about pride and making it pretty - that is - maybe it's the reason, but it's not what brings success in that area.
I think it's because, when it looks good, it's easier to find the information, and it makes you want to look at it. It makes you want to work with it.
Now then again while I realize github has a huge, huge amount of things running at the same time, I do find github quite a bit slower than my "own" remote repos :P
Don't mind the haters that think twitter bootstrap is a good enough UI wrapper, those are some pretty sexy graphs.
As a developer I'm totally jealous of the ability to create simultaneously elegant and usable UI/UX, even when I used to try and just copy the CSS and structure right from the HTML source (I've since stopped) it was always missing that "je ne sais quois".
"When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through."
That's not actually true. You'll use the plywood because it's stronger and because it's not seen. You get both the cost savings and increased structural stability, which will get you more customers.
That's not the point Steve Jobs was making. The point is: if you care about what you do, you'll do your best even when you don't have to. Because as far as you're concerned you do have to.
Steve Jobs was a well-known woodcarver and carpenter. When he wasn't at Apple, he was usually found in his garage, finishing off a new wardrobe or a sturdy deck chair.
I believe it was sarcasm intended to show that just because Steve Jobs gives an example in a field he has no experience in doesn't mean you should take it literally.
Craftsmen absolutely think about what's stronger and more durable, not just what's nicest looking (especially for non-visible parts!). I've got a few pieces of pretty decent antique furniture that's made its way down to me in my family (stuff made by craftsmen, not by mass production), and the hidden pieces aren't finished or styled to the same degree as the front ones. The purpose of the back and other non-visible parts is to hold stuff together, not to look nice. I would also point out, from your own link, the specs for their "the ledge":
"available with a solid domestic walnut top, sides and doors with a plywood bottom and low voc finish or painted mdf."
(Of course, these little details about what's "the right way to do it" are rather irrelevant to the greater point, which is that if you're the type to want to do things the right way, you're going to do things that way. Just don't hate on plywood, it has its uses (and feel free to come up with the programming equivalent!))
Edit -- some more notes on plywood: a sizable piece of plywood (like for the back of a chest of drawers or bookshelf) is going to be stronger (especially with regard to bending, IIRC) and vastly cheaper than a solid piece of wood since it only needs thin pieces of veneer with good grain for the outer layers. And IMO, it looks nicer than having several individual solid-wood boards jointed together in parallel.
We have some amazing antique Persian and Korean chests in the house. Hand carved and split grain matched fronts and maybe sides, but the backs are plain and/or rough hewn. These pre-date plywood, but the same goes - don't waste effort on parts that will never be seen, just build them to do their job.
It's "strong enough" and very light to ship. That's the only reason.
It's not strong enough for a lot of tasks and is definitely not good quality. One water spill and throw it away as the laminate just peels off - even on the expensive stuff.
I've taken to buying second hand good quality furniture (which is usually available at the same price as the shitty Ikea stuff) and stripping and painting it.
NeXT went on to go broke and sell their factories for pennies on the dollar, becoming synonymous in silicon valley with excess where it isn't required
edit: for those that don't know, that jobs quote is in reference to why they put so much effort into their factories, which really were ridiculous.... jobs went on to just outsource everything after his return to apple
Perhaps a better analogy was made by (General Sir Peter de la Billiere I think) about UK troops patrolling in Helmand Province.
He said something like "Even when they think no-one is watching, no sargents, no generals, they still monitor their surroundings, check the garden walls as they pass. No-one is letting the monotinity reduce their awareness."
In short, if there is a job worth doing, its worth doing well.
Doing your duty in the military is serious business, especially in a war zone with insurgents, everyone's life is on the line. So your quote isn't an apt analogy to furniture or software interfaces. Not all jobs are worth doing well, many are worth doing "well enough" given budget,time constraints and no lives at stake.
(Not to be too harsh, but I'm speaking from the experience of having been in the military and having spent years in the software industry.)
Part of it's high quality polish and finish is the lack of seams and protrusions and screws. This necessarily means something that's difficult to open up.
You can make an argument that they made the wrong trade-off between aesthetics and pragamatism, but for the trade-off they made, they executed well.
Plenty of tools get by being ugly, but that's not the point. Github is killing it right now, and they're killing it by having a very well designed product that developers really like to use.
Thinking of your (team's) effort as a zero sum equation can get you in to trouble. Yes, you only have limited time and effort, but on the flip side, all the time you spend doing something, you're training. By building ugly things, you're training yourself to build... well... ugly things.
I very much agree. I'm a (grad student) statistician and most of my time is spent developing models, running simulations, etc.. But once I have all the results, I need to find a way to present them in a way that is both informative, and inviting.
So I had to learn how to make beautiful plots. I used to be terrible at it, but one of my supervisors was very strict about plots: he would literally refuse to read reports in which plots weren't perfect (even draft reports). So I learnt how to make great plots (using ggplot2 for those who know R). At first, it took me forever to make any plot. Now, I can make very good ones in seconds.
So yes, instead of thinking of zero sum games, think of it as training.
I'd rather work for a product company like GitHub than, say, a consultancy building apps for many many clients, for reasons just like this. When you have a team working on one product that ships to millions of users, you've constructed a giant lever. As Spolsky put it, "Essentially, design adds value faster than it adds cost." [1]
Your developers' efforts create enough value (once spread across millions of customers) that you have plenty of resources left over to take care of every little detail. And some of those details may include tools that make your developers' lives easier. There is great value in well-designed abstractions like GitHub's dashboard: the human brain can only hold so many details at once. When 2 dozen little details are organized onto an internal dashboard, your developers' brains can visualize them and load them into working memory in an instant, freeing them to work on harder problems more quickly and with less detail juggling. This is very freeing and relaxing, and can even help developers see possibilities they couldn't see before.
You can't justify tools like this for every $50K Rails-App-in-a-Box, but companies like GitHub and Google certainly can.
Yes, you should. Whatever time was spent doing this is recouped a hundredfold by making this data so easily accessible to any engineer working on the project. I'd have killed to have this kind of stats at my fingertips, especially on projects where I don't have access to the production server to dig through the logs.
Yes, because part (actually most) of a project (and what you should be worried about managing) is the people who build it and people who use it. People are complex with many needs and desires above and beyond crapping out the cheapest product in the shortest time.
Should I feel bad knowing that ... someone wasted valuable time...
No, but you should feel bad for thinking "it looks pretty" ==> "someone spent a lot of time making it look that way."
In particular, what you need to consider is: maybe they didn't spend all that much time on the visuals. Maybe they were either just really experienced, and it took next to no effort to get it to look that way... or maybe they had next to no knowledge, but used a framework to make it look as if they did.
I find this is a very common mistake managers make, BTW: assuming they can estimate, in the blink of an eye, how long it took to get a certain feature or behavior of an app into existence, out of nothing (and quite often, getting this estimate off by an order of magnitude in one direction or the other).
Ugh, this comment really gets under my skin. I'm so glad that GitHub has a nice looking back-end, especially if employees have to look at it all day. That's one of the reasons the company I work for utilizes Twitter Bootstrap, because not only does it reduce development time, but it looks good too. Also, it's just CSS. It doesn't take that long to swap out the values of some of the colors. Unfortunately, this is the typical project manager response I've come to know.
I redid an admin tool from plain html to bootstrap. It actually provided less functionality, but because it was prettier people thought it did so much more.
Really, prettier makes it easy to consume the information you want to, which is just as important as getting that info on the screen.
Why should internal tools be ugly? Well designed tools help people work better and more efficiently—putting a little bit of thought into them is not a waste of time.
You are focusing on the time needed to make this. That is only one part of the equation. The other part is the time spent using it.
If this is (and it seems likely) an internal tool that gets used a lot, pretty soon the time it took to make it a little bit prettier/user-friendlier will be repaid in multiples during the entire lifespan of this application.
You know, I've been asked recently "what kind of company would you like to work for?". I had no answer then, just said that definitely not Google or Facebook.
Now I think GitHub might be that kind of company :)
Code, design, backend design, it all matters. If your code is shitty, your product is shitty. If your internal tools are badly designed, you can feel it on the frontend.
I'm amazed by how smart decisions Github make. They dare to focus on things that are not obvious important, but make a huge different for the employees. The employees in return make a world class product.
I really enjoyed this post, and it keeps me ever inspired to thrive for good design: Nn code and in graphics. On the backend and on the frontend.
"I'm amazed by how smart decisions Github make. They dare to focus on things that are not obvious important, but make a huge different for the employees. The employees in return make a world class product."
It's run by great developers, that's why. They understand the psychology of a great developer.
What part is gratuitously pretty? As a dashboard it looks pretty basic to me with an easy to look at color and lots of graphs to quickly figure out if there are any issues.
A couple of non-romantic justifications/reasons for ya :-)
* It may well have taken substantially less time than you think. Once an organisation has a structure in place for how the UX of a web app should run, and infrastructure in place for making sure things are coded up to that standard (standard templates, test suites, process, etc.) then these things can go together very quickly. I don't know how github runs it's UX/design side - but they seem like the sort of folk who'd streamline the heck out of the process.
* Wearing my UX hat - most of what you see isn't hard. It's basically having decent typography choices, decent vertical rhythm, good visual hierarchy. The icons look off-the-shelf from somewhere. This stuff doesn't actually cost any more time to do right the first time if you already know what you're doing (just like good DBAs automatically write normalised schema).
* With something like this - which is a mode switch between the "nice" stuff that your customers see and the stuff that you see as a developer - it's easier to keep everything nice rather than make the context-switch in development between nice/nasty.
* Wearing my ux-speaking-to-developers hat - think of it like technical debt. Yeah - maybe you could throw something together quickly that would do the job. But if you leave it in it has a knock on effect with everything you do next. It makes tweaking and extending stuff in the future more difficult. Keeping the UI clean, like keeping the code clean, may cost a little more up-front but will save you time in anything but the short term.
* Good UIs are more effective. Making the tools that the internal folk use to make the site better more effective seems like a good choice to be making.
Github has so much raw talent on staff that such things are totally reasonable indulgences. Why would Kyle be happy working on it if it was going to be ugly. It's that drive for excellence that motivates the kind of people Github hires.
I think it would be a major management mistake to force (or even urge) someone like Kyle to do things half ass.
It's not half-ass if you're achieving excellence by some other metric. I personally take pride in my ability to recognize tradeoffs. I encourage my peers to see things in the same light.
I'm that way too, nor am I a designer. My point was just that if you have one of the best UX designers working on something then the point is probably to have him/her optimize for functionality and design... otherwise it would have been fine to have someone work on it who was only skilled at the engineering aspect of the project.
I work for an agency, and I always find myself thinking that if we're content to settle for 2nd-rate tools for our own use, are we really in a position to say that what we're offering clients is 1st-rate?
It's easy to go overboard with making something pretty when it's in-house, but at the same time I genuinely find that I'm more productive when using pretty software. It's probably the INFP in me, but when something is slightly off I find it incredibly distracting.
In the case of the github dashboard images in this blog post, they do look a little designed but nothing that would take an experienced interface designer more than an hour or so. Time well spent if it makes the idealists in your team happier.
"Allowing the standard of quality to be set by the buyer, rather than the builder, is what we call the flight from excellence. A market-derived quality standard seems to make good sense only as long as you ignore the effect on the builder's attitude and effectiveness.
In the long run, market-based quality costs more. The lesson here is,
Quality, far beyond that required by the end user, is a means to higher productivity."
Sorry, but with respect if I ever had to work under someone who thinks like you I would probably have to quit my job. If I was your boss, I would probably have to fire you (as someone else said). I can only imagine you would happily run a restaurant which is kept immaculate up front, but the kitchen and employee conditions are a disgusting mess because "who gives a fuck?". Design is not just some pointless eye candy to make "pretty stuff", design is integral to usability. If you want efficient and happy employees and love their job and want to make their company succeed, don't skimp on important details. As well as anything else, when you give your employees the shitty stick constantly, don't be surprised when all this shit starts to creep into the customer facing experience. I suppose this would just be more "romantic" thinking though.
Let's have a look at how much marginal effort this takes:
- time spent thinking about what needs to be on the page (not extra)
- time spent thinking about what order the data should be displayed (not extra)
- time spent laying out the data (extra)
- time spent replacing the default font on the stylsheet (extra - minimal)
- time spent with getting graphs together (extra - but it is a skill. Once having done it, they could do this over and over)
Overall, I think the marginal time spent is well justified. Put it this way, your company probably hires cleaners to clean the office every day - that's a recurring cost. The cost sunk into a nicer design template gives the workers a nice working environment - that's significantly cheaper.
I could quibble with the three "extras" too :-) Assuming the data needs to come out in some format or another there would be some work in displaying it, and some work in getting it out and doing useful stuff with it. They're "different" not "extra".
In my experience designing things nicely doesn't really cost more than designing it badly. In both cases "design" is being done - it's just that in once case you have an expert involved.
If you were a project manager, I'd hope you wouldn't be imposing your personal tastes on a product.
I don't make products for me. I make them for my audience. The right question to ask isn't, "Do I care about how pretty this is?" It's, "What do my users care about?"
Consumer-focused products (and Github is certainly one of them) require much more investment in visual and interaction design than, say, in-house software. It's how many people judge quality, and having a pleasant experience matters to a substantial chunk of the audience. Github has absolutely made the right choice in keeping their interface a pleasure to work with.
You could raise the same argument about all the time they spend releasing open-source software, or producing the really great presentation slide decks that they do.
Regardless of the fact that a well-designed application encourages people to use it more, the fact that GitHub provide their employees with the opportunity to produce such well-polished interfaces is an incredible marketing tool for potential new recruits.
At the end of the day, it all fosters an environment where developers want to be The Guy That Works at GitHub, and all the great talent they attract just bolsters their position even more.
I see your point. But, if you don't care about what you are doing it will show. If you care and allow your developers to care about what they are doing, you will breed a culture that people want to be a part of. Sure it's lost money in the short term but that's short term thinking. It's better to let developers be happy and passionate about their work than to complain about the bottom line. In the long run you will extract far more value from a passionate dev over a burned out one.
Other people are going to look at this page hundreds or thousands of times, often in moments of crisis, so investing in making it easy to read/understand is a no-brainer for positive ROI on time. As for "making it pretty", it's not like this is chock full of gradients and exotic fonts and custom background images--in fact there's no reason I can think of why simple, pure-CSS designs would take any longer to develop if they're pretty than if they are not.
An ugly add-on to their normal pages would look hackish and unimportant. If that number went up dramatically, it looks both less important (than if it was prettier) and less reliable (if they didn't bother formatting the number, did they really check its accuracy?)
For what it's worth, if you were working for me, you would be instantly fired.
This is exactly the kind of opinion that perpetuates the mass of low quality crap in the world. It's an example of cutting corners, and long-term, it ends up costing so much more than it saves.
Not just practice: designing for co-workers will give you the most extensive feedback you'll ever get. When the guy in the next office can shout at you very time the contrast is a little funny or the spacing is kind of ugly, those details make their way into the public-facing side of the project as well.
Edit:
I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than 10 minutes of actual focus) and think to myself: "If that were me, I'd feel like I was just goofing off"
Get the information there. Make sure its nice and and usable. This does more than that though, which is great. I personally just would feel like I was wasting time and energy worrying about picking a color scheme when I had other work to be done.
Third thought: I appreciate the romantic justifications mentioned in the replies. I think they're fairly superficial, but they are romantic, and thats fine. I think the real difference here (and the root of the disagreement) has to do with why I associate this with 'waste of time'. There is obviously opportunity cost of doing this. I expect people most in favor of this stuff are salaried and not really concerned with opportunity cost. If I were salaried, I wouldn't feel like I was doing something wrong by doing this work because I'd do in in addition to my other work. I'd stay late and do it because I enjoyed doing it. I don't have that luxury where there isn't much opportunity cost because I'm paid by the hour. I don't work over-time. I'm not going to spend an extra hour at work one day to take care of this, so if its going to get done, its going to have to be prioritized over my other work. If picking colors (however important it is) is the most important thing on my to-do list, I have a problem.
TLDR: I'm paid by the hour. Thats probably why I feel this way.