An example will probably help make the issue more clear.

The structure we’ll use is simple. A “container” div wth an explicit width will contain all our content. Each test case will be a “holder” div, which contains the paragraphs with negative margins to pull them beyond the boundaries of both parent elements.

In a standards-compliant rendering, elements can be caused to extend beyond containing elements, through the use of negative margins:

Internet Explorer, of course, plays by different rules. Let’s start by looking at IE6:

When no width is set for the holder div, the paragraphs with negative margins are shown to extend beyond their holder div, but are clipped at the edge of the container div. However, when we explicitly set the width of the holder div to 100%, the paragraphs are clipped at the edge of the holder div - they’re not allowed to extend past any of the containing elements (more correctly, the content does extend past, but it’s inappropriately truncated, as though overflow: hidden; were declared on holder divs).

The same results are obtained in our second result set. When we declare the width in pixels, the paragraphs are clipped at the edge of the holder div. When we explicitly declare the width to be auto (same as the default property for block-level elements), content is clipped at the edge of the container div:

With Internet Explorer 7, we get yet another curveball. IE7 does properly honor the negative left margin in all cases, regardless of whether (or how) we declare a width for the holder div. The right negative-margin isn’t so lucky. It still gets truncated exactly the same way as IE6:

It’s almost like the dev team created a unit test for left negative margins and decided they were all set.

To their credit, the IE8 team has fixed right negative margins, based on the current beta:

So, if your site has sizable numbers of IE users (which, I think, is most of us), be aware that negative margins can cause unexpected consequences. Explicitly declaring overflow: visible; on holder and container has no impact on the resulting page renders. For the LSN launch, I ended up using relative positioning to achieve the desired affect.

Have a different workaround? I’d love to hear about it. In the meantime, here’s the testcase I put together.

Our team uses Skitch a lot. It’s a pretty invaluable tool for communicating visual information - you can easily annotate screenshots or comps. There’s great communicative value in being able to point at something, and as a remote employee in my past two jobs, I can’t imagine ever collaborating on web work without it.

Aside: Skitch is Mac-only, but I’ve heard good things about Jing if you’re on Windows. I don’t know of an equivalent solution on Linux, unfortunately.

Skitch does a lot of things well, but one bit of polish which always pops out at new users is the “Click to Clipboard” functionality. Skitch provides lots of ways for you to share your images, and when you click in the appropriate field, the site copies all the data to your computer’s clipboard, and presents a nice confirmation that you’re ready to paste that elsewhere:

I decided to create a workalike function in jQuery, my favorite javascript library. I got a rudimentary version up and running a while back, building on the approach Jeff Larson wrote up, over at http://www.jeffothy.com/weblog/clipboard-copy/.

Today, I was able to get my workalike polished up and turned into my first jQuery plugin - it’s available at http://github.com/chrispatterson/jquery-clipboard/tree/master. There are still some pieces of polish I’m planning to add, but I’m pretty happy with it so far.

Using the plugin

Note: this assumes that you’ve downloaded jQuery (http://docs.jquery.com/Downloading_jQuery), the jQuery Flash plugin (http://jquery.lukelutman.com/plugins/flash/), and the jQuery Clipboard plugin (http://github.com/chrispatterson/jquery-clipboard/tree/master). All examples can be used at the bottom of the page (immediately before the tag), or set to fire with $(document).ready

To add “click to clipboard” behavior to the element with an id of share-link:

$('#share-link').clickToClipboard();

To add “click to clipboard” behavior to all elements with a class of shareable:

$('.shareable').clickToClipboard();

clickToClipboard allows you to customize how long it takes for the notice to fade out, as well as the message used (for cases where you don’t want to use an image).

To have a slower fade effect, starting 1.5 seconds after the target element loses focus:

$('#share-link').clickToClipboard( {fadeoutLength: 900, fadeoutTimer: 1500});

To customize the notice text:

$('#share-link').clickToClipboard( {clipboardText: "You're ready to paste!"});

The look and feel of the notice is totally customizable through CSS. I’ve included a demo in the github repository, which shows how it might look with a background image. This is my first jQuery plugin, so I’m definitely open to feedback on ways to structure things better, or enhancement requests on how it be more flexible about supporting stuff folks need.

I’d seen http://24ways.org/2005/swooshy-curly-quotes-without-images a while back, and decided to improve upon it for the new Streetsblog site. In particular, the floated close quotes in Simon Willison’s approach will often leave a lot of whitespace.

The first version I’d done looked fine, and is what we launched with, but after a while folks found an odd renderbug. Internet Explorer (versions 6 and 7) would drop the quoted text down by about 2em, but only if the quote fit on a single line.

This week I was able to track down and fix the issue.

Here’s a screenshot of our launch CSS, as rendered by standards-compliant browsers:

Here’s a screenshot of our launch CSS, as rendered by Internet Explorer:

After a little digging, it became clear that the issue was IE inappropriately using the line-height for the opening quote for the entire blockquote, in those cases where the blockquote fits on a single line.

Lots of tinkering with line-height and vertical-align properties ensued - those have got to be the least consistent CSS properties I’ve run into for a while, and will probably be the subject of a later post.

Eventually, I ended up with something that worked in standards-compliant browsers:

And looks fine in IE7:

IE6 has an issue with line-height still - it will incorrectly indent the second line of text, to make room for the floated open quote (because IE6 ignores our explicit height declaration for that element):

That’s a tradeoff I’m willing to accept, in this case.

Markup for Better Blockquotes

<blockquote class="selfclear">
<span class=”open-quote”>&#8220;</span>
Fiction is obliged to stick to possibilities. Truth isn’t.
<span class=”close-quote”>&#8221;</span>
</blockquote>

Note: The selfclear class is a variation of the clever method originally written up at Position Is Everything - used to clear floats without unnecessary markup.

CSS for Better Blockquotes

.selfclear:after {
content: “.”;
display: block;
height: 0;
clear: both;
visibility: hidden;
}

.selfclear {
display: inline-block; /* IE 7 */
}

.selfclear {
display: block;
}

* html .selfclear {
height: 1px; /* IE < 7 */
}

blockquote {
font-style: italic;
color: #191f2f;
font-size: 1.3em;
line-height: 2em;
}

blockquote .open-quote,
blockquote .close-quote {
font-family: georgia, serif;
color: #6b707e;
font-style: normal;
font-size: 4em;
line-height: 1em;
}

blockquote .open-quote {
float: left;
height: 0.35em;
padding: 0 0.1em 0 0;
vertical-align: -60%;
position: relative;
top: -0.1em;
}

blockquote .close-quote {
vertical-align: -50%;
padding: 0 0 0 0.1em;
}

Replace the fonts and colors as needed for your design, and you should be all set!

As we move towards devoting greater and greater resources towards developing the Xinha Editor, we are faced with an interesting set of issues and opportunities: not only do we have to determine the degree of user control we allow but also—and to some degree as consequence of that—we have to question certain fundamental assumptions about the (in)appropriateness of the WYSIWYG model.

User Control

In recent conversations with Jackie I argued for limiting (though I prefer to say managing) user options to increase user happiness. My justification for this is best described by the adjacent line graphs.

Our editor should make it easy for our users to create documents for the web, but it should not provide so many options as to be stressful or confusing. As Kathy Sierra says, “the amount of pain and effort should match the user’s perceived payoff”. She even has a neat graphic. Our users want control and ownership of their pages, and that is something with which we provide them, but at what point do we provide so many options that the user no longer feels in control of the page?

We need to tailor the editor to fulfill the needs of our users: basic word processing, including basic inline type styling (bold, italic, underline, strikethrough, color); list creation (ordered and unordered, definition lists(?), and nesting); table creation and management (table stying, row and column manipulation); image inclusion; hyperlinking and page creation (wicked, internal, and external should be consolidated). But, we don’t need to provide much more… in fact we probably shouldn’t provide things like: font families, absolute font sizes, perhaps even text alginment (left, right, center)…

The WYSIWYG Model

…because the WYSIWYG model, as we have been thinking about it, may not be the ideal way of fulfilling these (perceived) needs. As Luke and I discussed it: the WYSIWYG model is predicated on emulating the experience of a typical word processor, specifically in regards to designing for presentation, and thus fails engage with the medium that is the web. As stated above, our editor should make it easy for our users to create documents for the web. The concept we have been working with emphasizes presentation (how things look) when it should equally emphasize structure (how things work) and semantics (what things mean).

To provide our users with a better experience we need to better understand web standards (like A List Apart) and incorporate all three modes of thinking/editing into our editor in a way that is easy for users to understand. WYMEditor, an example Luke pointed out, works on a WYSIWYM model and emphasizes the meaning of content over its presentation.

The WYSIWYM Model: Ideas About Implementation

It’s possible and desirable to implement core elements of the WYSIWYM model in our editor in several ways:

+ Clean Markup

Producing acceptable (X)HTML is perhaps the technically most difficult yet also more important thing for our editor to do. There is little point in focusing on the presentational niceties if the markup won’t render correctly anyway. The markup produced should strive to be structurally and semantically proper, conform to standards, and not be contaminated by visual information like font styles and weights, borders, colors, etc.

We can accomplish by limiting certain tags (like the evil “font” tag), running operations on the output markup to ensure a base level of acceptability, and outsourcing visual information to pre-defined CSS classes that are applied at the block level wherever possible. Ideally the editor could even be aware of the block-level context and provide only those styles which are appropriate to that block type (for example table styles for tables, list styles for lists, etc). By constraining users’ choices intelligently we make it easier for the user to get things done. Furthermore, if we don’t provide clean markup then any future support for theming or alternate styles will result in extreme pain for both us and our users.

+ Semantic/Structural User-end Views

The editor should make the structure of the page transparent to our users, either by default or through a toggle (like the ¶ button in Microsoft Word). As you can see from their demo, WYMeditor does a good job of this (they clearly leave out presentational elements as they are committed to a “pure” WYSIWYM model). This level of information benefits our users because they learn to think of the web as distinct from print media and enables them to build pages that will function across themes and Deliverations without breaking.

We can accomplish a similar effect using CSS specific to the editor context that adds borders, backgrounds, margin, padding, and (vernacular) labels to the block-level elements as we determine to be appropriate.

Testing the waters

It’s hard to work for a technology company without living in the shadow of Google. TOPP is pretty keenly aware of the big G not only because many of our employees applied there (some even turning down job offers) but also because their New York headquarters has a looming presence just a few blocks uptown. Many of our policies are reminiscent of theirs—including free lunch, flex time, and frisbees—to name just the ones beginning with F. One policy in particular that had always struck a chord with me, however, is Google’s idea of 20% time.

We’ve been experimenting with 20% time here in the Design Team at TOPP and it has proven incredibly valuable at making us more effective. Starting in July, Chris started on a limited form of 20% time that made him responsible for allocating some of his time as he saw fit for dealing with web design issues brought up by developers that were outside the scope of his primary priority. Issues that he saw taking longer were kicked upstream for more formal prioritizing. We made sure he wasn’t being spread too thin by making sure to include recaps at our weekly meetings.

After extending the pilot to Phil, I’m convinced it is a good idea.

Extending the scope

Now we are ready to broaden the scope of 20% time and extend it to the whole team. For those of you who haven’t heard, the Google Way encourages employees to take 20 percent of their time to work on something company-related that interests them personally. While ours is currently limited towards ‘putting out fires’, I want to extend it a bit beyond that and bring a few steps closer to Google’s model.

I want all members of the Design Team to take 20% of their time and manage it as they see fit, be it as one day a week or an hour and a half a day. While I still want maintenance and support of existing projects to continue to be the driving priority behind 20% time, any time left over in excess of that could go to: pairing with TOPP developers on new projects, like Anil’s Survv idea; contributing to existing open source projects of value to TOPP, like Sonali’s work on Xinha; writing a blog post for a TOPP-sponsored blog, like this one; developing a TOPP Talk or a talk that represents TOPP at a conference; reading a book from the TOPP library, especially if turning it into a blog post or TOPP Talk; or countless other things.

Obviously it’s difficult to tell where to draw the line with 20% time and it’ll probably take us some time to strike the right balance. To reiterate, I still want maintenance and support of existing projects to continue to be the driving priority behind 20% time. We will continue to review the use of one’s 20% time at our weekly meetings, which shouldhave the dual purpose of cross-pollinating our efforts and helping us find the boundaries of what is acceptable use of that time. Things that fall outside the scope of 20% time include personal projects of no relation to TOPP, like redesigning a friend’s website or planning a personal vacation. When in doubt, the easiest way to find out whether something would be appropriate or not would be to ask me.

There you have it, now use it! My first use of 20% time will probably be finishing that much-delayed blog post on “Open Source Design”, I suggest yours include a perusal of this New York Times article on the Google Way.

A few months later, in the breezy courtyard of an Italian monastery, Andreas Hocevar and I discussed the idea a little further to begin spec’ing out what it would require. We determined that any killer mapping app would need not just annotations comparable to those in Google’s My Maps but could really innovate by providing substantive map making tools—the ability to add and manage layers, style them, and export/share the finished map with the world. Like Google Maps, it would have to allow users to collaborate and share maps, but could go a step further by providing simple versioning and commenting. But unlike Google Maps, it would allow users to actually create their own maps rather than rely on the one provided. Users interested in hydrology could create maps focused on watersheds and flood plains, while users interested in social justice could create maps highlighting relationships between race and poverty.

Eventually, more advanced features like the ability to create and display buffers or allow others to copy maps while tracking their genealogy would seal the deal. Using these tools, a clever user could combine a preexisting hydrology map with a preexisting social justice map to produce a hard-hitting map showing the environmental justice issues surrounding a catastrophe like Hurricane Katrina. Most importantly though, users would not need advanced GIS knowledge or software—like what was required by many to produce such maps in August of 2006—but could instead create them easily and quickly through the web.

Andreas and I resolved that for such an application to work it would need to be easy-to-use, non-jargony, and most of the technology would have to happen ‘under the hood’—it should just work. Different projections, for example, should only appear when an unresolvable conflict arises and caching should be determined automagically based on how much traffic a map gets. A major impediment to this is the inaccessibility of good data, and I don’t know whether we can get over that hump.

The Problem

I was tossing and turning in bed the other night thinking about a proposal. Something wasn’t sitting quite right with me, there was something amiss about the proposal that I couldn’t put my finger on. Then it occurred to me that the sidebar was all wrong—not just how it was being used, but that fact that it existed at all. When the initial suggestion was made it was an easy solution to the problem of finding a home for the comments. In proposing an off-the-cuff solution to a minor problem, however, we had inadvertently boxed the entire project into a faulty paradigm.

Desktop application vs. Web application

We kept thinking of the map as a desktop application with a monopoly on screen real estate as opposed to a web application that can exist in a myriad of spaces and configurations. We had basically imposed upon users (both producers and consumers) a map which could only be used one way: alone, full-screen, with little context.

The reason that things like Google Maps keep popping up in every corner of the web is because they can. Google makes it incredibly easy to produce and disseminate maps. and his ease of use has lead to widespread adoption—it doesn’t take a computer scientist to figure out how plop one into a blog post. We, on the other hand, not only make it hard to consume maps, by disallowing embedding in our OpenPlans software for ’security’ reasons, but are now on a path to make it difficult to produce maps as well.

As an example of our narrow focus, picture the map as it is now—running edge-to-edge on our luxuriously large monitors. Looks neat, eh? A real application will all these neat pop-up effects. Now shrink it to a generous width of 620 pixels and embed into a blog post, like so:

See what happens with the sidebar? It takes up 340 pixels (well over half) of the room available on the map and leaves no room for the pop-up itself, which is supposedly the star of the show. Clearly this model is not going to cut it.

The Solutions

Fortunately, we don’t have to reinvent the wheel. Google Maps already provides us with a working model of how to approach mapping on the web. Much of this model has already proven itself on the web and established conventions as to what sort of interactions users expect. We don’t have to start from scratch with new models to be innovative when instead we can build on others’ successes and contribute our own competitive advantages.

We don’t need to fight Google head on when we can instead build to our strengths. We can improve on their model in several ways, including: better organizing the information in our pop-ups; providing better collaboration tools, such as comments and history; and being more open about how we import, export, and share data. The latter two are primarily technical issues (though they likely have interaction aspects), so I am going to focus primarily on the first: how we structure our pop-ups.

Anatomy of a Pop-up

Why add more objects to the interface when we should instead improve the one we have? Rather than arbitrarily using a sidebar to collect metadata about a marker, we’d be better off leveraging the pop-up itself. Doing so is not only more intuitive for the user, but also declutters the interface and simplifies issues of trying to synchronize state between the pop-up an a sidebar.

As Google and Yahoo have proven in their mapping applications, the pop-up can be a very versatile tool. Unfortunately, it can also be a bit unweildy if improperly structured or inconsistently used. My proposal is that we scrap the sidebar and instead structure our data using the carefully defined pop-up structure on the right.

• The red section in the upper left is the title and describes the entire object.
• The orange section just below is for different views on that object including notes, comments, and history—though one could see contexts in which other would be appropriate, perhaps ‘team’ and ‘tasks’ if it is a view of an OpenCore project.
• The green section in the center contains the content of a particular view and is the only section that scrolls if the content exceeds the maximum pop-up size.
• The blue section in the lower left is for state-changing actions related to the current view, such as adding a comment when in the comments view or editing the notes when in the notes view.
• The purple section in the lower right is for actions or resources that terminate or are supplemental to the current state, such as a comment feed when in the comment view or the save/cancel options when editing the note.
• The white section in the upper right is reserved for actions that are attached to the entire pop-up, not a particular view within it.

Although these conventions should be adhered to as much as possible, they should not be a hindrance to the user and should be deviated from in exceptional circumstances.