Tumblr Redesigns Edit Theme Panel
Smart move by tumblr allows you to actually edit your custom html in window. Solid little built in text editor.
Chartbeat threw up a new landing page this AM. please just let me log in. or, if I am logged in, please don’t make me click through this strange intermediate step. It’s pretty, but it slows me down.
Google is serious about this whole design thing »
Agree with @kn0thing that it’s a solid video. Even more interesting to me is Google’s obvious intent to create a friendly, “styled” feel for the page. Though they could do with a nice bit of css3 hover state on that button.
Apple discovered a new feature! Full screen windows! »
I love OSX, I really do. But I love apple’s self laudatory announcement on finally adding fullscreen windows even more.
I wish I could get Genndy Taratovsky to do some web design. The man is a genius. Dexter’s Lab, Powerpuff, Samurai Jack. Think about what he could do with html5 or an iPad game.
This is an attempt at redesigning the tutorspree profile page that I built mostly for practice. We’ve hired a designer to make something significantly better, but going from a blank page to this felt pretty good (though clearly it’s not good enough). As I take over more and more of the front end work from Ryan, it will be tests like this that make me better. HTML/CSS can be pretty very time consuming, and as we ramp up and load balance responsibilities, creating a release valve (me) for handling it is critical.
In any case, our real new profiles will be up soon, as will our whole prototype.
Background courtesy of Loryn Brantz, author of the very awesome Harvey the Child Mime.
undoing unwittingly bad design
Don Norman has a section in The Design of Everday Things where he mentions an interesting principle that I’ve never thought deeply about, and violate all the time. The basic point? Make instructions absolutely clear and simple. Case in point? On the Gentleman’s Guide I called the email subscription section “Electronic post” and had the button to subscribe labeled “Erudition, please.” Aside from being slightly over the top (even for the voice I use when writing the blog), it is an opaque description of what you get from that button. I’ve already changed that. It’s an incredibly small element of the actual design, and I don’t know that it will actually garner me any more subscribers, but it’s an important step in making the design actually user friendly as opposed to what I perceive as user friendly from my point of view as creator.
design of my everyday things
Lots of good reading over the past few days, from the four steps to the epiphany to the design of everyday things. Together, the two give me a lot to think about with regards to how I design things, and makes me see the things I have built in the past in a new light.
During my last job, I was responsible for overseeing our tech group in the creation of a productivity/workflow tracking and management system. I found myself in a position of constraint. On one side, the consumers and users of what I was creating wanted to see a very broad range of information in easily digestible form (though they had a hard time agreeing what exactly they wanted and why) and on the other side, I was constrained by the available technology (or, more precisely, constrained into a particular, non-optimized technical solution).
As I look back on that situation, it violated both Steven Blank’s and Don Norman’s theses, at the same time. The majority of our requirement gathering was done on one end of the end consumer (as opposed to user) side of the equation. The technology developed was not, itself, flexible enough to actually allow for changes based on customer feedback, and the constant request for more features was not tamped down. I tried to please everyone by adding in everything. The end result was a piece of software that did some things decently, many things poorly, and that eventually crashed in on its own infrastructure (more of a technical fail of scaling than anything else, but also a result of trying to do too much). When I look at the design of what we built itself, it made sense from a certain perspective, but was very much lacking in terms of convenient and easy interaction for the primary user. Simple things, like a total hours capture (for end of the day book keeping) were absent, and could not be created later without material investment from our tech team. That’s the opposite of agile, and the opposite of functional design. In fact, it is exactly what happens when engineers are given a boatload of features marked “must have” and told to just fit it in.
Though I was at a large company and did not have actual control or decision power over what basic architecture we would use (to maximize extensibility and eventual scaling), and I did what I could to make the design choices as clean as possible, knowing what I know now, I would have charted a very different course through that project. Namely:
1) create an explicit hierarchy of needs for the product based on both user and consumer requirements (which, at its heart, includes a definition of what our market actually was)
a) includes extensive customer feedback sessions based on mockups pre- build (what Blank refers to as demos - without a full working model)
2) design evaluation with the users: actually observe them using the product before making it a requirement, instead of assuming they would learn all the tricks I knew from designing the thing (don’t rely on knowledge in the head)
Granted, this was not a startup situation, but the lessons are still incredibly relevant. We may have still run into trouble based on some of the root choices and abilities that were unavailable, but I think we could have done better. Great lesson.
