<?xml version="1.0"?><!-- RSS generated by Radio UserLand v8.0.6 on Sat, 20 Sep 2003 17:42:09 GMT --><rss version="2.0">	<channel>		<title>john robert boynton: Web - Usability - Humor</title>		<link>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/</link>		<description>licentious radio</description>		<language>en</language>		<copyright>Copyright 2003 john robert boynton</copyright>		<lastBuildDate>Sat, 20 Sep 2003 17:42:09 GMT</lastBuildDate>		<docs>http://backend.userland.com/rss</docs>		<generator>Radio UserLand v8.0.6</generator>		<managingEditor>jrb@tdl.com</managingEditor>		<webMaster>jrb@tdl.com</webMaster>		<category domain="http://www.weblogs.com/rssUpdates/changes.xml">rssUpdates</category> 		<skipHours>			<hour>2</hour>			<hour>3</hour>			<hour>4</hour>			<hour>5</hour>			<hour>1</hour>			<hour>6</hour>			<hour>0</hour>			<hour>7</hour>			</skipHours>		<cloud domain="radio.xmlstoragesystem.com" port="80" path="/RPC2" registerProcedure="xmlStorageSystem.rssPleaseNotify" protocol="xml-rpc"/>		<ttl>60</ttl>		<item>			<description>Stupid html tricks.... This is in Windows help, but why shouldn&apos;t it be as bad in a browser?It says &quot;For help on scheduler, click here.&quot;&quot;Here&quot; is blue and clickable. But on hover, it becomes bold. Because the width of the characters changes, &quot;here&quot; moves to the next line on hover. You can&apos;t click on it. You point at it, and it moves to the next line. You have to change the window size before you can click on it???Don&apos;t do bold on hover.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/08/27.html#a1863</guid>			<pubDate>Thu, 28 Aug 2003 04:49:51 GMT</pubDate>			</item>		<item>			<description>Ha ha.licentious radio is the first site in Google search results for &quot;licentious&quot;. We&apos;re proud, mighty proud.We&apos;d like to thank all the *little* people who made this possible. We never expected this honor. We only try to do our best. If we can cause one smile, we feel like we&apos;ve accomplished something. We&apos;ll use any notoriety from this honor to promote world peace and save the animals.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/08/09.html#a1756</guid>			<pubDate>Sat, 09 Aug 2003 16:31:18 GMT</pubDate>			</item>		<item>			<description>Exciting improvement in Windows and Perl!The ActiveState Perl install (using a .mci) automatically installed to drive F. What? Why doesn&apos;t it ask you where you want to put Perl? It&apos;s too smart to ask? Why drive F? Because it&apos;s there! We turned off the external drive F, and ActiveState installed to drive C without asking. Imagine our relief!Way to go, boys!</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/08/08.html#a1750</guid>			<pubDate>Fri, 08 Aug 2003 22:59:35 GMT</pubDate>			</item>		<item>			<description>Why task-switching is unbearable on the Mac....Some developers are glad enough for unbroken features of the Mac that they put up with the rest.Not many.You more or less have to drink the kool-aid.Those un-pre-disposed find insurmountable obstacles, task-switching in particular.Why?Because if developers started developing for OS X, Microsoft would snuff it. As long as OS X is just a music/photo/video platform for the rich, Bill is happy: give up a few points of market share as cover against charges of monopoly, and steal anything that catches attention.But the user interface has to be focused on morons and boosters so very few independent develepers make software for it.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/06/15.html#a1694</guid>			<pubDate>Mon, 16 Jun 2003 00:35:52 GMT</pubDate>			</item>		<item>			<description>MS Mission Accomplished!Seattle (licentious) -- Microsoft founder Bill Gates announced &quot;Mission Accomplished&quot; on board the aircraft carrier Ken Olsen today. &quot;Major combat operations in the web browser business have ended,&quot; announced Gates, while standing under a huge banner reading &quot;Mission Accomplished&quot;.&quot;Because of you, our monopoly is more secure. Because of you, the competition has fallen, and the internet is in chains,&quot; was his message. &quot;The board of directors is grateful for a job well done.&quot;The carrier landing and speech were to announce the end of development of Microsoft&apos;s web browser -- used by 85-95% of web surfers. The Macintosh version will be eliminated like Jimmy Hoffa, and future development of Windows IE separate from the operating system will be in &quot;maintenance mode&quot; only -- akin to the preservation of Lenin&apos;s corpse in Moscow&apos;s Red Square.According to Gates after the speech, &quot;We paid good money for this monopoly -- $25,000 to John Ashcroft, specifically. It&apos;s time to take advantage of our total victory and stop wasting money on a technology that only supports our enemies.&quot;Gates also announced a new commitment to standards: &quot;Whatever we say, goes.&quot;Internet webloggers pointed out that browser development at Microsoft continues, but will be embedded in specific products that support Microsoft&apos;s overall strategy. For instance, while Mac IE is deader than Osama Bin Laden, a new and improved browser is embedded in the Mac version of the subscription-based MSN service. Microsoft also says the next release of the Windows operating system will contain a new version of IE -- that won&apos;t be available for previous versions of the Windows operating system. MSNBC pundits on board the carrier noted a gigantic bulge in the crotch area of His Billness&apos;s flightsuit. The three supposedly heterosexual middle-aged men discussed at great length how sexy Bill appeared with the giant bulge, and that they knew women would be positively drooling to get at Bill&apos;s &quot;product&quot;. Journalists not on Microsoft&apos;s payroll were somewhat less convinced.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/06/14.html#a1685</guid>			<pubDate>Sat, 14 Jun 2003 16:24:15 GMT</pubDate>			</item>		<item>			<description>Further adventures of &amp;amp;shy;....For those of you just tuning in, licentious radio&apos;s NO JUSTIFICATION in HTML campaign is sweeping the web.Why? Because justifying text without hyphenation typically leaves uneven. gaping holes between words, where a single, small space should be. Even though the right edge is nicely even, the gaping holes and running rivers (a hole at about the same place in several lines) make reading difficult. If you intend for people to read the text on your website, making it harder to read than normal is a bad idea.Of course we can&apos;t say X without pondering the opposite of X. When could you justify text? Newspapers get away with it because of hyphenation and narrow columns. We postulate that with sufficiently narrow columns, the eye doesn&apos;t scan along the line as much, so irregular and large spaces between words wouldn&apos;t be such a big problem.Not content to leave well-enough alone, we had to hack. Putting soft hyphens (&amp;amp;shy;) in text is easy. Modern browsers will at least ignore the &amp;amp;shy; -- we thought. Sigh. There&apos;s no end to the blundering of browsers. (We&apos;re complaining, not accusing. Browsers are hard and making browsers fast was harder, and all of this would have been fixed long since had the development pace kept up.)WinIE 4+ will use &amp;amp;shy; to hyphenate. Mozilla ignores them gracefully. Alas, MacIE 5x (on one Mac with OS X, anyway) displays a U with some queer accent for every &amp;amp;shy;.Not content to leave bad enough alone, we hacked onward: write a script in Javascript to go through and remove the soft hyphen characters. (We had thought Javascript was finally stable enough to be useful....) Alas. Our simple-minded hack freaked MacIE out completely -- throwing margins off and twisting the font-family. (Why in the world didn&apos;t they test this?)Reluctantly, we abandon the concept. (The coolest bit was we got to align headings to the right. You don&apos;t get to do that every day.)Fact is, WinIE&apos;s hyphenation was pretty bad -- not hyphenating often enough -- and our view is that hyphens should hang -- be placed just beyond the right margin -- which WinIE doesn&apos;t do. This design had very short lines... we might try again in a design where the lines are a more normal length and the server is smart enough only to give &amp;amp;shy;s to WinIE browsers.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/05/25.html#a1657</guid>			<pubDate>Mon, 26 May 2003 02:22:49 GMT</pubDate>			</item>		<item>			<description>Tantek (Thursday) said it&apos;s too easy in CSS to wind up with columns of text overlapping each other. That&apos;s for sure. Rather a usability problem when that happens.Using tables for page layout, the problem is a column stretching widely.Example -- you put an image in a column that for one reason or another is bigger than the column woulda/shoulda been. With tables, the column becomes too wide. With CSS, the image blots out whatever is in the next column.Many people keep designing as if they know how wide every reader&apos;s browser window is, and how big the fonts are. It would sure be convenient if HTML and CSS made it *easy* to get things right, rather than making it so easy to get things wrong. Even min-width and max-width -- where supported -- don&apos;t seem to be good enough. I&apos;d want to be able to specify max-width as 100% of the browser window for narrow windows, and also as 33 ems for browser windows that are open wide.Another problem is the way float works. Commonly, you get text columns that are much too wide or much too narrow, depending on the width of the browser window. Tables make it pretty easy to make a page that is wider than the window, while float makes it very difficult. In some cases it&apos;s fine if a third column of text or ads is completely off the right side of the window. Rules: A column of text should never be wider than the window. A column of text should never be wider than some number of characters -- 33 ems is pretty good. A column of text should never be wider than a certain absolute distance -- four or five inches, maybe. For narrow windows, you might want the first column to be no more than 75% of the window, so the second column is visible. That is, if you have a narrow window, you may well want the columns to go off the right edge of the window (for left-to-right languages).A technical consideration is that if you have nested divs, the width of the outer div doesn&apos;t constrain the width of the inner divs -- the way tables would.Another technical consideration is that floating several columns to the left only works for the width of the window. Float is pretty convenient, until you would rather have a column be off the screen than below the other columns.Float-left hack: For the right column, set a containing div to one pixel wide, then the contained div with the content can be any width -- it will go off the window to the right. But there has to be one pixel left going across. (The first trick is use float: left for all columns.)</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/05/25.html#a1655</guid>			<pubDate>Sun, 25 May 2003 21:58:03 GMT</pubDate>			</item>		<item>			<description>Met up with the traveling &lt;a href=&quot;http://stopdesign.com/&quot;&gt;Doug&lt;/a&gt;/&lt;a href=&quot;http://tantek.com/log/2003/05.html#L20030522t2247&quot;&gt;Tantek&lt;/a&gt;/Todd show Thursday evening. Some of the CSS conversation was drowned out by a bluegrass band, but the cafe itself was all right. Tantek and Todd each had a copy of Zeldman&apos;s new book. All three of them are in the book, having each made significant contributions to standards and/or use of standards.Topics touched upon included png transparency for ie, the Zen Garden website (a site where numerous designers have contributed stylesheets to show how thoroughly the stylesheets influence the appearance), styling form fields, whether multiple posts without permalinks constitute a weblog (mostly a joke), and vigilante drones.Someone mentioned acronyms in passing, which was a hot topic several months ago. I never got around to writing about acronyms, but I have several suggestions.... 1) Authors could indicate acronyms with all caps (IBM). 2) The CMS can insert acronym tags. 3) Less is more in formatting acronyms -- better not to underline every occurence. 3) The CMS can make a glossary of acronyms used in a page. 4) Style acronyms that are all caps to be a smaller font size, maybe .85em. That&apos;s not as good as using a real small-caps font, but it&apos;s probably better than using full-sized caps. (Better in that full-sized caps strongly emphasize, which is typically inappropriate for acronyms.) 5) You could still display a tooltip of the expanded text of the acronym, even though not everyone would know to look for it. After all, most people will already know most acronyms, and they should be defined on first use anyway. 6) A good CMS would have a dictionary of acronyms and let you set rules for how and when to use the acronym tag -- you might not want to tooltip &quot;HyperText Markup Language&quot; for every use of HTML, for example.Heather T. and I were the only ones to join them. Maybe next time they&apos;ll avoid the bluegrass and give a little more notice. If you&apos;re interested in CSS, web standards, and such, take advantage of the chance to hang out with these guys.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/05/24.html#a1652</guid>			<pubDate>Sat, 24 May 2003 17:07:01 GMT</pubDate>			</item>		<item>			<description>Just for the anti-zeldman record: the latest addition to the local stylesheet for Zeldman&apos;s primarycontent is &quot;color: black&quot;. Oh. Nice, readable, black text.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/05/21.html#a1638</guid>			<pubDate>Wed, 21 May 2003 05:09:00 GMT</pubDate>			</item>		<item>			<description>Random Rant on the font tag....Putting a font tag in every freaking table cell was pretty silly.On the other hand, it worked. &quot;Worked&quot; in the sense of letting users pick the default text size, and reliably scaling the text size from there across platforms. The fact that some designers picked the typically unreadable &quot;font size=1&quot; for body text was not the fault of the font tag.CSS has a way to do essentially the same thing, but Microsoft broke it by picking different relative sizes than the rest of the world. That is,  the CSS equivalent of size=2 is one step different on Windows IE than on most other browsers.Then there&apos;s a Windows IE bug for sizing text with em units in CSS -- some users will see .9em as unreadably small.I&apos;m sure Billionaire Bill&apos;s heart breaks when he hears about these bugs that make it vastly more difficult to create websites that look OK on both Windows IE and other browsers.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/05/03.html#a1585</guid>			<pubDate>Sat, 03 May 2003 17:59:49 GMT</pubDate>			</item>		<item>			<description>&lt;a href=&quot;http://www.meet-the-makers.com/conversations/neumeier/&quot;&gt;A Conversation With Marty Neumeier&lt;/a&gt; [meet-the-makers.com].Marty Neumeier was the editor of Critique, a quarterly magazine about &quot;graphic design thinking&quot;.Critique was great. I miss Critique almost as much as I miss prosperity. Since Critique folded, when I&apos;m near a magazine rack, I just sigh and turn away.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/04/24.html#a1578</guid>			<pubDate>Fri, 25 Apr 2003 00:03:35 GMT</pubDate>			</item>		<item>			<description>A little problem with the tabs at the Google search engine....Problem: mouse cursor changes over the tabs, but only the text is clickable. This is actually *very* bad usability... needlessly tricking people. (This affects Gecko -- Netscape/Mozilla...--  browsers, and at least IE 5 -- windows and Mac.) Solution: Add to the .q styles (the &apos;a&apos; tags in the tabs): &lt;tt&gt;width: 100%; display: block&lt;/tt&gt;With the width at 100% of the table cell, the entire tab is clickable. Gecko browsers need &quot;display:block&quot;, though IE5win doesn&apos;t.When the entire tab is clickable, you don&apos;t need the cursor style in &apos;td&apos; tag for each tab:&lt;tt&gt;style=cursor:pointer;cursor:hand;&lt;/tt&gt;That way you even save a few bytes. (Even if you don&apos;t add the CSS for the &quot;q&quot; class, you should take out the cursor styles.)You could also add &quot;width: 100%; display: block&quot; to the style for tabs on the news page (.d).</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/04/07.html#a1539</guid>			<pubDate>Mon, 07 Apr 2003 19:31:54 GMT</pubDate>			</item>		<item>			<description>Google queries that led people to licentious radio today:&lt;ul&gt;&lt;li&gt;george bush 11 september speech&lt;li&gt;what do you think of bush&apos;s radio address on iraq&lt;li&gt;/usr/lib/ipkg/info/opie-irdaapplet.postinst configure&apos; failed&lt;li&gt;republican voter fraud&lt;li&gt;greenspan interest rate&lt;li&gt;Neil Bush&lt;li&gt;linux for ipaq 3800&lt;li&gt;Israel halliburton&lt;li&gt;ipaq install network card&lt;li&gt;humor radio&lt;li&gt;emil ruder&lt;li&gt;CSS div absolute table cell&lt;li&gt;&quot;ordered list&quot; stylesheet&lt;li&gt;Interest rate - greenspan&lt;li&gt;madplay radio&lt;li&gt;hitler breaking treaties&lt;li&gt;ipaq radio&lt;li&gt;George Bush press conference, transcript&lt;li&gt;ipaq and radio&lt;li&gt;typography golden section&lt;li&gt;12 iraqis surrendered march 2003&lt;li&gt;neil bush&lt;li&gt;interest rate greenspan&lt;li&gt;neil bush&lt;li&gt;&quot;I&apos;m the person who gets to decide,  not you.&quot;&lt;li&gt;&quot;download microsoft fonts&quot;&lt;li&gt;graphics kind of peace&lt;li&gt;Schwarzkopf france deer hunt&quot;&lt;li&gt;&quot;zapping electronics&quot;&lt;li&gt;squeeze breast&lt;li&gt;usability humor&lt;/ul&gt;On a good day, a few people find answers to technical questions, and a few people find entertainment. We&apos;re on the second page of results for &quot;Neil Bush&quot;. You can tell Neil is in stealth mode (after nearly getting Reagan whacked, and stealing A FREAKING BILLION DOLLARS from American taxpayers, and having Corrupt Brother Jeb shovel money down his throat).Every now and then somebody takes the time to say &apos;hi&apos; or asks a question.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/03/10.html#a1391</guid>			<pubDate>Tue, 11 Mar 2003 04:39:08 GMT</pubDate>			</item>		<item>			<description>Yes, it starts to seem like Tantek day at licentious radio, but I get to cross an item off my to do list.Here&apos;s the &lt;a href=&quot;http://radio.weblogs.com/0102813/other/pgexplanationnada.html&quot;&gt;polygon document&lt;/a&gt; with no dtd -- works in Mozilla 1.1.And here&apos;s the same document with a &lt;a href=&quot;http://radio.weblogs.com/0102813/other/pgexplanationstrict.html&quot;&gt;strict dtd&lt;/a&gt; -- works in Mac IE 5.It occurs to me that with the dtd-hacking that browsers do, there *might* be a dtd declaration that works for both Mac IE and Mozilla. </description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/03/07.html#a1377</guid>			<pubDate>Fri, 07 Mar 2003 19:57:06 GMT</pubDate>			</item>		<item>			<description>Way back in 1997/1998 I said HTML needs a clean &apos;client-side include&apos; -- to let you include a bit of HTML from an external file. The *main* issue is that you shouldn&apos;t  have to specify the height and width. That saves you from having to assume the user&apos;s font size.Anyway, HTML 4.01 has the Object tag, that can be used this way. Your church-website can include the same navigation bar on every page using the object tag.The next problem is support. My Mozilla 0.8 doesn&apos;t support Object. If you look at &lt;a href=&quot;http://tantek.com/log/2003/03.html&quot;&gt;Tantek&apos;s weblog&lt;/a&gt;, he uses Object to include a blog roll. Mozilla 1.1 on Linux displays several screens of it, then leaves a black blotch for the rest. Scrolling line by  line converts the blog roll to noise. Mozilla 1.2.1 on Mac displays a screenful, but ignores the rest. Tantek&apos;s own Mac IE 5+ gets it right.I guess this means we can start using Object in two to four years.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/03/07.html#a1376</guid>			<pubDate>Fri, 07 Mar 2003 16:25:38 GMT</pubDate>			</item>		<item>			<description>If Google ads are so tied to the search query, why did &quot;mozilla html object tag&quot; give me an ad for: &quot;GirlSummer Academic Camps&quot;?</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/03/07.html#a1375</guid>			<pubDate>Fri, 07 Mar 2003 15:38:12 GMT</pubDate>			</item>		<item>			<description>&lt;a href=&quot;http://tantek.com/map.html&quot;&gt;Tantek &amp;Ccedil;elik&lt;/a&gt; has been writing in some detail about the W3C meetings in his &lt;a href=&quot;http://tantek.com/log/2003/03.html&quot;&gt;weblog&lt;/a&gt;. Interesting stuff. [Note to W3C: let&apos;s keep HTML and variants easy -- for people -- to create and use.]Tantek&apos;s site map is &lt;a href=&quot;http://tantek.com/map.html&quot;&gt;made of CSS hexagons&lt;/a&gt;. It&apos;s very slick. In my browser-of-daily-use, though, it&apos;s even slicker. I use some ancient Mozilla -- 0.8 or so -- which didn&apos;t quite have everything right. It turns Tantek&apos;s symmetry into chaos: &lt;a href=&quot;http://radio.weblogs.com/0102813/images/tantekmenu.png&quot; target=&quot;screenshot&quot;&gt;screen shot&lt;/a&gt; [opens in new window because screen shots are a drag].</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/03/07.html#a1374</guid>			<pubDate>Fri, 07 Mar 2003 15:16:56 GMT</pubDate>			</item>		<item>			<description>&lt;a href=&quot;http://scriptingnews.userland.com/backissues/2003/02/27#When:6:45:08AM&quot;&gt;Dave Winer&lt;/a&gt; [userland.com]: &quot;Here&apos;s what Google can do for weblogs that would be a service to the weblog community -- classify and group them. Give me an accurate list of all the librarian weblogs, and all the lawyer weblogs, and all the weblogs of people who have implemented an XML-RPC stack. You get the idea. They have been able to do this with news stories, it seems they should also be able to do it with weblogs. This is the biggest unsolved problem I see in this world, and I don&apos;t know how to solve it, it&apos;s not what I do. Postscript: Tom Matrullo wants this too.&quot;My suggestion is use the Open Directory categories -- maybe enhance them -- and let weblog writers self-select. There&apos;s no reason to restrict this to weblogs, of course. It would let you establish a context for your search phrase. Search for &quot;mustang&quot; under horses, or under cars.Google&apos;s trick of categorizing news articles is slightly different from categorizing weblogs and websites: Google has a very small number of categories for news, and most news articles are about one topic. If the software isn&apos;t sure about one article, it can just leave it off the front page. If it ever guesses wrong about an article, the article disappears off the front page in a matter of hours.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/02/27.html#a1354</guid>			<pubDate>Fri, 28 Feb 2003 02:59:45 GMT</pubDate>			</item>		<item>			<description>Man! I just wasted half an hour trying to create a table in MySQL with a TEXT field. My O&apos;Reilly MySQL &amp; mSQL book has a table on page 98 that makes it look like you give TEXT a character size. Then I glance at the text below, which talked about a performance hit if the contents of the field went over the size you specify. Alas, the text below the table was talking about mSQL, and the table itself appears just to be a lie. Maybe it&apos;s out of date.Anyway....create table test (item text(500) );gives you this helpful message:ERROR 1064: You have an error in your SQL syntax near &apos;(500) )&apos; at line 1It should be:create table test (item text);</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/02/14.html#a1284</guid>			<pubDate>Fri, 14 Feb 2003 22:13:44 GMT</pubDate>			</item>		<item>			<description>&lt;b&gt;Update&lt;/b&gt;: Sigh. The hexagon stopped working in Mozilla, once Radio built the final page for the weblog. It works in the Radio CMS. Now, I&apos;m not terribly surprised. If you use invalid HTML, you can&apos;t expect every feature to work exactly right. Still, it would be nice if things were a little more robust. I&apos;ll put the example into a separate file so the trappings of Radio and my &quot;design&quot; don&apos;t mess with it.&lt;a href=&quot;http://tantek.com/&quot;&gt;Tantek &amp;Ccedil;elik makes &lt;a href=&quot;http://tantek.com/CSS/Examples/polygons.html&quot;&gt;polygons with CSS&lt;/a&gt;. Works in Mozilla and recent IEs. Very interesting. I&apos;ve always eschewed big borders the way I avoided Dallas&apos; &quot;big hair&quot; styles, so I hadn&apos;t thought of doing this before.But the &lt;a href=&quot;http://tantek.com/CSS/Examples/polygons.css&quot;&gt;stylesheet&lt;/a&gt; and even the HTML are quite complicated -- because he&apos;s re-using and cascading abstractly.My goal here is to simplify the styles as much as possible. Because I&apos;m running this through the Radio weblog software, I had to use the style attribute, rather than a separate stylesheet.&lt;h4&gt;Take a very simple case:&lt;/h4&gt;&lt;a style=&quot;	border-bottom: 1em solid blue;	border-top: 1em solid blue;	border-left: 1em solid yellow;	border-right: 1em solid yellow;&quot;&gt;hey baby&lt;/a&gt;Here are the styles:	border-bottom: 1em solid blue;&lt;br&gt;	border-top: 1em solid blue;&lt;br&gt;	border-left: 1em solid yellow;&lt;br&gt;	border-right: 1em solid yellow;Now it&apos;s easy to imagine that if the width is one pixel, but there are left and right margins, you could make a triangle by displaying only the bottom border.&lt;a style=&quot;	border-bottom:4em solid blue;	border-top: none;	border-left:2em solid transparent;	border-right: 2em solid transparent;	display:-moz-inline-block;	display:inline-block; 	margin:0;	height:0; 	width: 1px;&quot;&gt;&lt;/a&gt;The html can be as simple as:&amp;lt;a class=&quot;triangle&quot;&amp;gt;&amp;lt;/a&amp;gt;And here are the styles:	border-bottom:4em solid blue;&lt;br&gt;	border-top: none;&lt;br&gt;	border-left:2em solid transparent;&lt;br&gt;	border-right: 2em solid transparent;&lt;br&gt;	display:-moz-inline-block;&lt;br&gt;	display:inline-block;&lt;br&gt;	margin:0;&lt;br&gt;	height:0; &lt;br&gt;	width: 1px;In this triangle, the height is the border-bottom size, and the width comes from the size of the border-left and border-right.Now think about a hexagon. The top of a hexagon is shaped like the bottom border, and the bottom of a hexagon is shaped like the top border. You just need to get the sizes right. CSS makes this easier. Use ems to get the right relationship between the sizes, and set the font-size in pixels to determine the actual size of the hexagon.&lt;a class=houter style=&quot;	font-size: 10px;	border:none; 	display:inline-block; 	text-align:center;	width: 10em;	height: 8.66em;&quot;&gt;&lt;b class=&quot;htop&quot; style=&quot;	border-left: solid blue; 	border-right: solid blue;	border-bottom: solid;	border-top: none;	display:-moz-inline-block;	vertical-align: text-bottom; /* keeps together in moz */	color: green;	display: inline-block; 	margin: 0;	height: 0; 	border-width: 4.33em 2.5em; 	width: 5em;&quot;&gt;&lt;/b&gt;&lt;b class=&quot;hbottom&quot; style=&quot;	border-left: solid yellow; 	border-right: solid yellow;	border-top:  solid;	border-bottom: none;	display:-moz-inline-block;	vertical-align: text-bottom; /* keeps together in moz */	color: green;	display: inline-block; 	margin: 0;	height: 0; 	border-width: 4.33em 2.5em; 	width: 5em;&quot;&gt;&lt;/b&gt;&lt;/a&gt;The html can be:&amp;lt;a class=&quot;houter&quot;&amp;gt;&lt;br&gt;&amp;lt;b class=&quot;htop&quot;&amp;gt;&amp;lt;/b&amp;gt;&amp;lt;b class=&quot;hbottom&quot;&amp;gt;&amp;lt;/b&amp;gt;&lt;br&gt;&amp;lt;/a&amp;gt;And here are the styles..htop {&lt;br&gt;	border-left: solid blue; &lt;br&gt;	border-right: solid blue;&lt;br&gt;	border-bottom: solid;&lt;br&gt;	border-top: none;&lt;br&gt;}&lt;br&gt;.hbottom {&lt;br&gt;	border-left: solid yellow; &lt;br&gt;	border-right: solid yellow;&lt;br&gt;	border-top:  solid;&lt;br&gt;	border-bottom: none;&lt;br&gt; }&lt;br&gt;.htop, .h2bottom { &lt;br&gt;	display:-moz-inline-block;&lt;br&gt;	vertical-align: text-bottom; /* keeps together in moz */&lt;br&gt;	color: green;&lt;br&gt;	display: inline-block; &lt;br&gt;	margin: 0;&lt;br&gt;	height: 0; &lt;br&gt;	border-width: 4.33em 2.5em; &lt;br&gt;	width: 5em;&lt;br&gt;} &lt;br&gt;.houter {&lt;br&gt;	font-size: 10px;&lt;br&gt;	border:none; &lt;br&gt;	display:inline-block; &lt;br&gt;	text-align:center;&lt;br&gt;	width: 10em;&lt;br&gt;	height: 8.66em;&lt;br&gt;}&lt;br&gt;Note that the houter element is required by MacIE to get the shape right. MacIE also requires at least an HTML 4 strict DTD. MacIE 5 refuses to display the width of the hexagon if you use no DTD or the HTML 4 transitional DTD. The &quot;vertical-align: text-bottom&quot; is required for Mozilla.Meanwhile, Mozilla has a problem using the strict DTD. I see a horizontal stripe in the middle of the hexagon with the strict DTD, but not when there is no DTD at all, or a transitional DTD. This page isn&apos;t actually valid strict HTML 4.01, so it&apos;s possible that Mozilla would handle the hexagon properly if the HTML were valid. But I see that problem on Tantek&apos;s page with the octagon. His page is probably valid.Just make the left and right borders transparent to make a more friendly hexagon:&lt;a class=h2outer style=&quot;	font-size: 10px;	border:none; 	display:inline-block; 	text-align:center;	width: 10em;	height: 8.66em;&quot;&gt;&lt;b class=&quot;h2top&quot; style=&quot;	border-left: solid transparent; 	border-right: solid transparent;	border-bottom: solid;	border-top: none;	display:-moz-inline-block;	vertical-align: text-bottom; /* keeps together in moz */	color: green;	display: inline-block; 	margin: 0;	height: 0; 	border-width: 4.33em 2.5em; 	width: 5em;&quot;&gt;&lt;/b&gt;&lt;b class=&quot;h2bottom&quot; style=&quot;	border-left: solid transparent; 	border-right: solid transparent;	border-top:  solid;	border-bottom: none;	display:-moz-inline-block;	vertical-align: text-bottom; /* keeps together in moz */	color: green;	display: inline-block; 	margin: 0;	height: 0; 	border-width: 4.33em 2.5em; 	width: 5em;&quot;&gt;&lt;/b&gt;&lt;/a&gt;To prevent the horizontal line in Mozilla, but keep the strict DTD, I&apos;ve wrapped the hexagon in a div, and removed the font-size styling:&lt;div&gt;&lt;a class=h2outer style=&quot;	border:none; 	display:inline-block; 	text-align:center;	width: 10em;	height: 8.66em;&quot;&gt;&lt;b class=&quot;h2top&quot; style=&quot;	border-left: solid transparent; 	border-right: solid transparent;	border-bottom: solid;	border-top: none;	display:-moz-inline-block;	vertical-align: text-bottom; /* keeps together in moz */	color: green;	display: inline-block; 	margin: 0;	height: 0; 	border-width: 4.33em 2.5em; 	width: 5em;&quot;&gt;&lt;/b&gt;&lt;b class=&quot;h2bottom&quot; style=&quot;	border-left: solid transparent; 	border-right: solid transparent;	border-top:  solid;	border-bottom: none;	display:-moz-inline-block;	vertical-align: text-bottom; /* keeps together in moz */	color: green;	display: inline-block; 	margin: 0;	height: 0; 	border-width: 4.33em 2.5em; 	width: 5em;&quot;&gt;&lt;/b&gt;&lt;/a&gt;&lt;/div&gt;</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/02/13.html#a1277</guid>			<pubDate>Fri, 14 Feb 2003 04:16:00 GMT</pubDate>			</item>		<item>			<description>The case for &lt;a href=&quot;http://www.google-watch.org/bigbro.html&quot;&gt;Google for Big Brother of the Year&lt;/a&gt; award.We just mention this Google stuff, we&apos;re not necessarily complaining about Google ourselves.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/02/13.html#a1272</guid>			<pubDate>Thu, 13 Feb 2003 21:43:06 GMT</pubDate>			</item>		<item>			<description>What to click. I watch movies on DVD sometimes. I have this 19-inch monitor. The clickable areas are *tiny*. They&apos;re hard to find. Just make stuff clickable, darn it.With stylesheets and a bit of automation, we can do better than we&apos;ve done so far. Say your homepage has headlines and one or two paragraph summaries or leads. The headline should be clickable, sure. But why not the text of the paragraphs?First, you don&apos;t want the text underlined, and you don&apos;t want the same *loud* hover indication. We can do that with stylesheets. Second, you don&apos;t want non-CSS browsers to have the whole paragraph underlined (because it&apos;s so much harder to read underlined text). So you have to be able to send *different* html to CSS and non-CSS browsers. You have to automate, and you have to have some server-side browser-sniffing. (Or easy client-side opt-in.) Third, you can&apos;t nest links. If the paragraph contains a link itself, that would require special handling. But *that&apos;s* OK, since you already have to automate. Just end the paragraph link before the link in the text, and start another link after. The specific link in the text should be obvious when you hover, so customers know that they&apos;re getting the right link when they click.As ol&apos; Jakob says, most customers spend most of their time at other sites, so not everyone will make use of a feature like this. Some people may even get confused by it, though they&apos;re more likely to wonder why other websites don&apos;t work like this, rather than why your&apos;s does. But some people will be helped, and that&apos;s what we&apos;re here for, right?</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/02/13.html#a1266</guid>			<pubDate>Thu, 13 Feb 2003 16:17:51 GMT</pubDate>			</item>		<item>			<description>&lt;a href=&quot;http://www.zeldman.com/daily/0203b.shtml#feb1303&quot;&gt;Zeldman found his bug&lt;/a&gt; [zeldman.com], in his Javascript. Javascript is dangerous stuff. It&apos;s easy to write something that works in one situation, but breaks unobviously when something -- seemingly unrelated -- changes.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/02/13.html#a1257</guid>			<pubDate>Thu, 13 Feb 2003 14:50:21 GMT</pubDate>			</item>		<item>			<description>The poor internet access providers. A few of their customers use a lot more bandwidth than the rest. Bandwidth hogs should pay more, right?At licentious radio, we like turning arguments on their head.The bandwidth cost to an access provider comes from wires, routers, maintenance, and the charge for spewing the bits onto the internet. The cost of the bits is what they&apos;re most complaining about. And yet, why is the cost per bit so high? In the 90s, we put down enough fiber to handle orders of magnitude more traffic across the internet than we use now. This unused capacity goes by the tragically romantic name &quot;dark fiber&quot;.In fact, as traffic increases, the cost per bit *falls*. This stands old-fashioned economics on its head. In fact, the cost per bit falls faster than the number of bits increases. *That* puts old-fashioned economics into free-fall.If internet traffic had risen faster, the bandwidth cost for access providers would have dropped.What slowed the increase in internet traffic? The access providers. The phone companies don&apos;t want you using the internet for voice calls. The cable companies don&apos;t want you sharing movies over the internet. Even AOL and its ilk wants customers trapped in &quot;mindless consumer&quot; mode -- for the pennies of ad revenue, but also to keep the customers away from competitors.If internet access were treated as a public utility, the total cost of our bandwidth would be lower, and we would have orders of magnitude more bits flowing around.How much bandwidth will we use? High quality video conferencing. Streaming video weblogs. Email home movies. When you go to an ecommerce site, you won&apos;t see a cheesy little picture of a product, you&apos;ll see print-catalog quality photos, and streaming video, and if you have a question, you&apos;ll get a sales person in live video. Plus we do more of everything we already do, and give it all to billions more people. And when we&apos;ve done all of that, you&apos;ll pay three bucks a month, not twenty.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/02/13.html#a1256</guid>			<pubDate>Thu, 13 Feb 2003 14:39:59 GMT</pubDate>			</item>		<item>			<description>A specific case for server-side browser sniffing.In general, it&apos;s difficult to get sniffing right, and you have to tweak the process over time. Most web teams aren&apos;t set up to do this well enough.But here&apos;s a case where it would be handy. Say your company buys 500 PocketPC mobile phones, perhaps to give salespeople easy 24x7 access to a browser-based sales support system. Cool. But it comes with the handheld version of IE.The handheld version of IE that came with my iPaq a year ago didn&apos;t do stylesheets, and it didn&apos;t even put a blank line between paragraphs. Targeting that browser, it would be useful if you could add some &quot;non-breaking&quot; spaces to the start of every paragraph, to indicate the break. Further, it&apos;s only choice for making table-based pages fit on the screen was to shrink *everything* so the entire width of the html page fit onto the three-inch screen. Not helpful. Neither is the alternative: scrolling right and left to read each line of text. So if your website normally uses tables for page layout, you gotta lose the tables before you send the page to the handheld. (Someday, we&apos;ll all use float for page layout, maybe, but not until we can have a footer go all the way across the bottom of the page.)This kind of scenario will crop up repeatedly. A group uses some funky hardware, for which only a funky browser is available, and so you go ahead and make some usability fixes. Once you&apos;re set up to do that for internal users, why not use the same technology for your customers. Why shouldn&apos;t a customer with a handheld get a version of the site that strips most of the page junk, and makes it easier to find/access/process particular information they might need immediately.</description>			<guid>http://radio.weblogs.com/0102813/categories/usabilityUsabilityHumor/2003/02/12.html#a1253</guid>			<pubDate>Thu, 13 Feb 2003 02:04:43 GMT</pubDate>			</item>		</channel>	</rss>