This is a nice success story for web developers, but there’s more going on than traffic:

…Apple takes a 30 percent cut of subscription revenue from users who sign up for apps in the store.

More problematic is that Apple wants to control subscriber data — valuable demographic information used by magazines and newspapers to sell advertising — from people who sign up for the app in the store.

For subscription-based publishers such as FT this is not a supportable position. One has to wonder if other successful subscription-based sites are equally dissatisfied.

Of course, what makes the FT story unique is that its web app replaced its Apple store app. For many organizations the platform app will never get built, not when a comprehensive web development effort can leverage some common UI and code to target both desktop and mobile users.

“App stores are actually quite strange environments,” Grimshaw said. “They are cut off from most of the Web ecosystem.”

Update: In regards to my last point before the last quote, Jason Grigsby’s Cloud Four critique of responsive web design is required reading. The mobile and desktop environments each deserve their own optimization.

(via a Tizra Facebook post)

The issue is this. Our new blog design has a 640 pixel width content column. The current design has a 690 pixel width content column. Any image or object in our archives sized to the maximum setting of 690 pixels wide will not fit the new format.

We are approaching this issue in two different ways.

First, about month ago, we set 640 pixels as the maximum image size in the current theme. This means that recent images are already optimized to work within the new design.

Second, the new design features a wide content margin. Using a negative margin CSS technique, images up to 690 pixels can extend into this margin without obscuring sidebar links or breaking the column.

There is a third solution. We can manually edit each post with a 690 pixel width image and replace it. That one awaits a design intern.

This demo page shows the Meta Web version we have purchased for the site redesign. Internally we have tested it on Internet Explorer 6, 7, and 8, and current versions of Firefox, Safari, and Google Chrome (such incremental browser testing is part of our process). It also works on the iPhone’s Safari browser.

If the fonts on the demo page don’t resemble the image below on your browser, let us know!

A sample of Meta

UPDATE (December 9, 2010): As Andy mentions in the comments, the lower-case y in Meta Web Medium renders with a flaw. This appears on all Windows-based browsers. We’ve reprocessed the fonts and uploaded a new demo.

Starbucks, like most other businesses is primarily interested in maximizing throughput of orders. More orders equals more revenue. As a result they use asynchronous processing. When you place your order the cashier marks a coffee cup with your order and places it into the queue. The queue is quite literally a queue of coffee cups lined up on top of the espresso machine. This queue decouples cashier and barista and allows the cashier to keep taking orders even if the barista is backed up for a moment. It allows them to deploy multiple baristas in a Competing Consumer scenario if the store gets busy.

This is a quirky article that introduces a number of programming concepts in an accessible and entertaining way. Hohpe throws in the occasional deep dive — as with the “Competing Consumer” link in the quote — but even there the analogy helps you guess where such a link might take you.

Analogy speaks to shared experience. It provides a way — one way — to turn abstract concepts into visual explanation. I can almost see the coffee cups lined up in front of me.

Historic New England selected Dynamic Diagrams to create the user experience for the site (research, information architecture, visual design, and XHTML and CSS coding). We worked with our development partners to implement a Plone content management system (CMS) that provides Historic New England — for the first time — with complete control to create their own pages.

The Centennial site is also a preview of things to come. Watch this space for a future announcement of Historic New England’s redesigned and enhanced main web site.

Fresh from Google Labs:  Google Browser Size, a nifty visualization tool for checking how much of a web page sits “above the fold,” i.e., what’s visible in Google without scrolling.  Just type in any URL to see how the site looks.  Color contours show different window sizes and the percentage of users that have this size or larger.  (Presumably these percentages are based on Google’s own statistics.)  For instance, in the example above, the “donate now” button falls within the 80% contour, meaning that 20% of users cannot see this button when they first visit the page.  If getting donations is a priority of the site, the web design team now knows they ought to position the button higher on the page.

The tool works as an overlay, allowing you to interact normally with the page you’re examining.  Thus you can easily review other pages on the site as well.  This is great for sites that are about to be redesigned, or ones that you’re just curious about.  I was also happy to discover that this tool also works for designs that are still in development–I was able to view a .png on a project site, which gave me instant feedback on what will be visible on page load.  Nice work, Google.

-moz-border-radius (for Mozilla-based browsers such as Firefox)
-webkit-border-radius (for Webkit-based browsers such as Safari)
border-radius (the probable CSS style)

None of these effects show on the current version of MSIE 7 — so let that be your control. Some may not show on Firefox until the release of Firefox 3.1, but all work on Safari using the Webkit syntax.

Headed by developer Dean Hachamovitch, the MSIE 8 team has decided to move its default mode away from MSIE 7 compatibility and closer to web standards. Spolsky offers a long quote from Hachamovitch’s announcement of this decision, but it boils down to this:

We’ve decided that IE8 will, by default, interpret web content in the most standards compliant way it can.

This means that some HTML pages coded to take advantage of some of MSIE 7′s quirks will break in MSIE 8.

This is a problem? It shouldn’t be.

Barring the introduction of any new quirks (say a new way to misinterpret the box model), there’s no reason any Web site HTML and CSS should break in MSIE 8. If a web site has been tested against MSIE 6, MSIE 7, Firefox, and Safari (as are all of our public-facing projects), and if its developers have used a robust HTML structure and the subset of mutually-supported CSS styles (rather than browser-sniffing to write specialty CSS), then the odds of that site rendering incorrectly in MSIE 8 should be very small.

JavaScript-driven functionality, however, is harder to predict. Here, I rely on the folks behind Prototype and jQuery to handle MSIE 8 so I won’t have to. We’ll see how that goes.

“Once the priority of a project is established, the team should immediately move toward visualizing that idea. This can take many forms, but we have found that whiteboards and large pieces of paper work wonders to get everyone on the same page. Nothing slows down the creative process like a 60-page document, complete with spreadsheets and appendices.”

This has been our experience as well. While some engagements do require some type of written narrative — especially in cases where there needs to be a more detailed explanation of the application for a broader group outside of the development team — we’ve seen immense value in translating requirements into a visual form during all phases of a project. I would take Banfield’s comments a step further by suggesting that visuals are not just helpful tools, but can often replace specification documents as deliverables. Diagrams (for expressing high-level user experience), process flows (for explaining complex transactions), and heavily annotated wireframes (for describing functionality at the page-level) are “closer to reality” than a Word document that describes them. This makes the idea behind an application easier to understand and discuss, leading a group to consensus about direction much more quickly.

Before moving forward, Polansky took a few steps back by employing traditional IA exercises such as wireframing (adapted to a more interactive experience) and usability testing to validate the direction and identify the holes. Besides pointing out the similarities and differences between building web sites and RIAs, he offers a good shortlist of pitfalls to avoid, including the potential for increased revision cycles and building interaction at the expense of content. I would tend to agree with him on both fronts. In our practice, we’ve found that constructing process flows and annotated wireframes are key to keeping everyone on the same page about the intended user experience and the possible trade-offs between vision and feasibility. These activities ease (if not eliminate) any worry of creating interaction for its own sake.