Googie architecture Where uses are in actual fact homogeneous, we often find that deliberate distinctions and differences are contrived among the buildings. But these contrived differences give rise to esthetic difficulties too. Because inherent differences—those that come from genuinely differing uses—are lacking among the buildings and their settings, the contrivances represent the desire merely to appear different. Some of the more blatant manifestations of this phenomenon were well described, back in 1952, by Douglas Haskell, editor of Architectural Forum, under the term “googie architecture.” Googie architecture could then be seen in its finest flowering among the essentially homogeneous and standardized enterprises of roadside commercial strips: hot-dog stands in the shape of hot dogs, ice-cream stands in the shape of ice-cream cones. These are obvious examples of virtual sameness trying, by dint of exhibitionism, to appear unique and different from their similar commercial neighbors. Mr. Haskell pointed out that the same impulses to look special (in spite of not being special) were at work also in more sophisticated construction: weird roofs, weird stairs, weird colors, weird signs, weird anything. Jane Jacobs, The Death and Life of Great American Cities Ducks and decorated sheds quirks
Reverse chronology bias Once you’ve had a taste of effortless updates, it’s awfully hard to back to manual everything. So they didn’t. And neither did thousands of their peers. It just simply wasn’t worth it. The inertia was too strong. The old web, the cool web, the weird web, the hand-organized web… died. And the damn reverse chronology bias — once called into creation, it hungers eternally — sought its next victim. Myspace. Facebook. Twitter. Instagram. Pinterest, of all things. Today these social publishing tools are beginning to buck reverse chronological sort; they’re introducing algorithm sort, to surface content not by time posted but by popularity, or expected interactions, based on individual and group history. There is even less control than ever before. There are no more quirky homepages. There are no more amateur research librarians. All thanks to a quirky bit of software produced to alleviate the pain of a tiny subset of a very small audience. That’s not cool at all. Amy Hoy, How the Blog Broke the Web Navigation by shibboleth timequirks
XXIIVV Webring A Website webring.xxiivv.com This webring is an attempt to inspire artists & developers to build their own website and share traffic among each other. wwwquirksblogging
Product vs. Feature Teams An Article by Marty Cagan svpg.com This article is certain to upset many people. Empowered product teamsViability, usablity, feasibilityWhat went wrong? featuressoftwareagile
Empowered product teams When I wrote about the virtues of empowered product teams, I was referring to what I’ll continue to call here as product teams. Specifically, they are cross-functional (product, design and engineering); they are focused on and measured by outcomes (rather than output); and they are empowered to figure out the best way to solve the problems they’ve been asked to solve.
Viability, usablity, feasibility In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us. However, in a feature team, you still (hopefully) have a designer to ensure usability, and you have engineers to ensure feasibility, but, and this is critical to understand: the value and business viability are the responsibility of the stakeholder or executive that requested the feature on the roadmap. What went wrong? teamwork
What went wrong? If something ships from one of the companies I advise, and it is virtually unusable because of poor design (which as we all know occasionally does happen), you can bet I go directly to the designer and ask how this happened? It is absolutely on the designer to ensure this does not happen, so something went wrong. Similarly, if the product ships and performance is terrible you can bet I go directly to the tech lead with the same question. And most frequently of all, if something ships and the analytics show that it’s either not being bought or not being used, or it turns out that it violates some business constraint like compliance or privacy, you can bet I go right to the product manager with that question. Viability, usablity, feasibility