meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Archive: 2004

S5 1.1a5

Hey, we’re moving quickly: S5 1.1a5 is now up.  The current testbed file uses XHTML 1.0 Transitional, the better to accomodate the “allow external links to open in new window” feature I added with prompting from Peter Murray and assistance from Dave Marks.  I’m thinking about generalizing the routines to just mark any link that starts http://... as an external, window-spawning link, but that to me seems a little too intrusive.  I tend to think it’s better to let the author mark which links should spawn new windows, and which should not.  If I’m wrong, let me know.

Among other bug fixes: incremental slides now wind and unwind correctly, and don’t leave the last point on the slide stuck in the “current” state even when you loop through the slide show more than once.  The show/hide for the controls has a slightly different behavior now, so I’m looking for feedback there.

The last bug I want to squash before exiting the alpha stage is that in Safari, when you click on an “external” link, it still advances the slide show one step.  All other browsers I tested (IE/Win, Firefox) didn’t, as was the intent.  I can’t quite figure out how to fix Safari’s problem, which seems to center on the new hasValue() function.

(singing) Beta slide show, here we come…

Caption Hunt

Over the last two days, some… odd pictures of the President and his new appointees have made the rounds.  Here they are:

I could use some cheering up, so if you’d like to help out, write funny captions for one or both pictures.  Extra credit for captions that don’t make sex jokes.  (Anything really foul will be deleted.  You have been warned.)

For those who wish to contribute two captions, I think we’ll be daringly original and refer to the first picture (of Bush and Rice) as #1, and the second (of Bush and Spellings) as #2.  Got it?  Great.  Knock yourselves out.

S5 1.1a4

Hooray, we’re up to 1.1a4!  The only real change here is that I’ve added a “what do you want to hide, the controls or just the popup menu?” feature.  This is handled with the following meta element:

<meta name="controls" content="hide" />

That will hide all the controls.  The default behavior is “show”, which shows the controls but not the menu.  The testbed file is currently set to hide the controls by default.

Only here’s the problem: the modifications I made broke the system in IE/Win.  It returns the ever-so-helpful message “Unknown runtime error” and a line number that doesn’t seem to make any sense to me, so I’m not sure exactly what’s broken, nor why.  Assistance appreciated. Okay, that problem got fixed with a rename suggested by Michael Moncur.  The problem now is the control menu doesn’t appear when you mouse over the lower right corner, although the controls show up okay.  This may be my fault, but help in figuring out how to make IE/Win consistent with Safari and Firefox is needed.  Thanks. Those of you using Safari or Firefox will see things as intended, at least until the IE/Win thing is fixed.  I’m especially interested in feedback regarding how the controls reveal and hide themselves in the testbed presentation.

I suspect I’m getting close to the end of feature additions for v1.1; at this point, I’d like to clear up any lingering bugs, possibly rework how the default settings are represented in the meta elements (but not their intent), and write up a quick guide on creating and using themes.  I think that will be more than enough.  I don’t want to try to tack on too much at once with each revision.

Our Own John Peel

Until a few weeks ago, I’d never heard of John Peel.  Part of this was due to my never having visited the United Kingdom (though I’ve flown over it a few times), and also to my only glancing familiarity with the “music scene” in general.  The news coverage that followed Peel’s sudden, unexpected death made me aware of both his existence and his love of music.  I felt as though news of a hidden treasure had been exposed for all the world to hear about, just when that unique voice had been forever silenced.

Now it’s my turn to do the same for the world.

This past Friday, the staff members at WRUW recieved word that Harold “Ayche” Freshour, host of “Demolished Sanctuary”, had died unexpectedly at the age of 41.  Harold was, in a lot of ways, our own John Peel.  He possessed an encyclopediac knowledge of music from all genres and periods.  It was very nearly impossible to reference a song that Harold had not heard.  He had his favorite classic groups, but he was also on constant lookout for interesting new artists.  A familiar face on the Cleveland punk scene, one of those guys everyone knew, he wrote a vast number of articles, reviews, and other pieces for music magazines.  It was fairly obvious from the first time I met him that Harold loved music to a degree that few people I’ve ever met could even begin to understand.  As an example of his vast musical knowledge, Harold covered my show a few times, and I heard from my listeners that he’d done a fine job.  Mine is not an easy show to cover—some weeks, I fail to do a good job.

Not only did Harold have that vast store of musical trivia in his head, but he was a truly a kind and wonderful man to boot.  He was forever filling in for other station members when they needed it, helping out around the station with cleaning or organizing, doing production work, and generally contrinbuting to WRUW with a smile.  He was always willing to listen and give advice when another person had a problem.  His was an even keel.

Harold was also deeply enigmatic.  Much of his life was compartmentalized, and many of the things I’ve mentioned in this etnry I have only learned in the days since he died.  I am certain that he touched and was an influence in other arenas, in ways we haven’t yet uncovered.  Perhaps we never will.  I suppose that we never really know how much a person changes the world during their life, but in Harold’s case there is an added layer of mystery.

These things will sort themselves out over time.  For now, I mourn the loss of a truly good man, and bring—though in many ways too late—news of him to the world.  In the end, it is the least I can do for him.

Rest well, Harold.

Great Big Food Show

Today, Kat and Carolyn and I spent all day at the Great Big Food Show down at the I-X Center.  This is the Food Network‘s road show, and it was held in exactly two very hip and happening cities this year: Philadelphia and Cleveland.  The show ran here for three days, and every day there were multiple appearances from Food Network stars Marc Summers, Mario Batali, Rachael Ray, and Alton Brown.  Oh, heck, who are we kidding?  The only real star in our personal cooking firmament is Alton, deeply wacky dude and hacker cook extraordinaire.  A photograph of Alton Brown with his arms around Eric and Kat.  We stood in line to get our copies of his books signed, and also to thank him for his Thanksgiving turkey recipe, which quite literally changed how we cook.  I also told him his Web site (specifically, the wonderful Rants & Raves) needs an RSS feed.  He told me he had no idea what the hell that means.  That’s all right.  Until Alton explained it on his show, I couldn’t have told you what a Maillard reaction was, let alone how it related to cooking.

So, clearly, I need a TV show, so I can return the favor.

We also saw Alton’s final stage show, where he did a sort of live-action espiode of “Good Eats” involving custards, eggnogs, ice cream, and other foam-based foods.  It was a lot of fun, with probably one or two thousand people in attendance.  I’ve heard that the other live shows were similarly popular, and with six shows a day over three days, that’s a lot of people.  Even if you figure some repeat customers, that’s still well over fifteen thousand.

What wasn’t fun was the show floor, which was far too cramped and therefore choked with crowds of attendees.  The only reason I can imagine things were so tight is that they didn’t want to pay for more floor space, because the show area was completely surrounded by empty space.  Rumor has it that next year they plan to make it even bigger, and I certainly hope that’s the case.  It was clearly a popular event, so I think they can afford to bump up the surface area.  That may mean a slight bump in ticket prices as well, but honestly, they weren’t terribly expensive so I think a small increase would be totally acceptable.  Especially if it yields more elbow room.

There were also vague promises of turning the live shows into a TV special.  I hope they make it two hours long, and call it the “Great Big ‘Great Big Food Show’ Show”.  The name actually rolls off the tongue more smoothly than you might expect.

In all, we really enjoyed ourselves.  Hopefully those of you in less-hip cities will have a chance to see the show next year.

S5 1.1a3

We’re up to 1.1 alpha 3, with the big news this time around being incremental display.  So far, the way this works is that you can class a ul or ol element, and have the bullets in that list be incrementally displayed.  This is easier to understand by seeing than by reading an explanation, so go check out the alpha testbed.  In the first slide, all the bullets are displayed incrementally; you move through them by using any “next” action (keyboard or mouse).  You can also back up using a “previous” action.  The exception to this is the next and previous controls in the lower right-hand corner of the slide.  These always move forward or backward by one slide.

On the first slide, all of the bullet points are greyed out until you advance through the slide.  On the second slide, the first point is pre-highlighted.  This is intentional; it shows the difference between the two ways of presenting an incremental list.  On the third slide, the main-level points are all normal but the sub-list is incremental.  Again, this is intentional.  The highlight effect is completely CSS-based (using the class current), so every theme can have its own incremental-display look.  I picked red because it was really, really obvious, and I was too lazy to think about what color would fit in better with the default theme.  I’ll get around to tidying that up later.

The one thing I’ve made the system do but am not sure about is that when you back up to a slide that has incremental display, it starts out looking normal and then “un-highlights” as you move backward through the points.  I’m not sure that this is desirable, but at the same time I think it could be very useful.  (Plus you can always skip back a whole slide by using the lower-right controls.)  I’d like to hear feedback on what people think about the way the incremental display works now, and how it could be better.

For those who want to play around with incremental display, you add a class of inc to a list whose items you want to be incremental.  If you want a slide to start with the first point highlighted, add psf to the class value, so you have class="inc psf".  If you want to reveal arbitrary elements one by one on a slide, individually class them with inc.

I don’t have all of the contributed code merged into the JS yet, but I’ve seen everyone’s contributions from earlier posts, so please be patient.  I’m still at a loss as to how to make the intra-slide links work in Safari, and could use help figuring out what’s wrong there.  To test it, hit the “skip to summary” link on slide 1 of the testbed.  For that matter, if you uncomment the li:after rule in pretty.css, you’ll see that Safari keeps adding “NaN” into the classes of incrementally-displayed list items when you move back and forth from one incremental slide to another.  I can’t figure that one out, either.  Help is always appreciated.

So from my original 1.1a2 to-do list, the following are still left to do:

  1. A way to choose whether to show/hide all of the navigation controls, or just the menu. Indicating the preferred behavior via a meta tag is starting to feel more like the right way to go, since it means the presentation author can decide whether he wants the controls to be visible or hidden.  The problem of exactly how to manage the behavior is as yet unresolved.
  2. Better, possibly more dynamic, theme selection.  I still don’t have a clear idea of how this would really work.  It might be better to simply write a clear description of how to associate a new theme with the presentation file, and write up guidelines for theme authors.
  3. A way to indicate the target resolution in the CSS, so that the scripts can use that for scaling purposes (and thus make the scaling more intelligent).  I’m actually leaning pretty heavily toward dropping this, because I don’t see a pressing need to include it at this stage.  For the purposes of scaling foreground iamges, it wouldn’t be much more powerful than the author managing scaling via CSS.

And there you have the current state of s5 development.  Feedback is welcome.  Ever forward!

Mailing List Community Care

Clay Shirky recently published a missive titled “Group as User: Flaming and the Design of Social Software” that I almost dropped into the Distractions list, but then realized I wanted to write about in a little more detail.  Clay talks about mailing lists as one of the oldest forms of social software, and how they tend to become clogged with flame wars.  He makes the case that since flame wars are inevitable in a group setting, there should be mechanisms that help prevent and control the fires.  For the most part, I agree with him that some mechanisms would be a good idea.  I do not, however, accept that flaming is inevitable.

I can draw on personal experience to make this claim.  I’ve been responsible for a mailing list (css-discuss) for almost three years now.  In that time, the list grew so large that it started to overload its home, and had to migrate to a more capable host.  As of this writing, the membership list stands at 5,128 subscribed accounts.  That’s not a typo.  Bear in mind that any account that is disabled due to excessive bounces gets automatically removed after a couple of weeks, so the amount of deadwood is pretty low.

So, yeah, I know what it’s like to be a part of a very large mailing list community.  Over the lifetime of the list, we’ve had very, very few flame wars.  (Most of them have centered around font sizing, unsurprisingly enough.)  And what we call a flame war would hardly even raise an eyebrow in most online fora.  By the standards of the css-d community, any thread that contains more than two agitated posts is considered a flame war.  Posts where list members actually insult each other are rare as moon cheese.  Condescension is a little more common, but not by much.

We aren’t running magic software to make this happen; the list is running on Mailman 2.1b5.  What’s made the difference is me.

Warning!  Ego alert!  Ego alert!

Actually, not at all.  From the very first, I’ve worked hard to make sure list members understand the nature of the community.  It is not a democracy, and it isn’t an anarchy.  It’s a benevolent dictatorship.  This is no secret: I’ve said so on the list at least a couple of times.  I try not to wield the Brickbat Of Administrative Correction unless necessary, and when I do, I do so in as neutral and even-handed a manner as possible.  In the end, though, I make it very clear that within the confines of that community, my word is effectively law.  I decide what’s on topic, and what isn’t, and gently make my decisions known.  End of story.  When I call for a thread to end, it ends.  Or else.  If list members ask for changes to the list’s nature, as happens from time to time, I listen to their reasoning and then make a decision.  That’s it.

Maybe that all sounds like a guy on a massive power trip, but honestly, I’d much prefer that I didn’t have to make those calls.  I’d prefer to have a community where the members keep themselves in line.  That’s actually possible so long as the community is very small, and everyone both listens and is heard.  In a large community, it’s effectively impossible.  Even if 99% of the list membership is adult, the 1% can ruin things for everyone else.  On css-d, a 1% flame rate would mean 50 members were out of line.  In absolute terms, that’s unacceptable.  Thus I actively watch and chaperone the list.  I also wrote some material enumerating the policies, how to avoid being offended, and the right way to answer questions.  People really like that material.  I’ve been asked permission to re-use that material several times.

I also participate in the community as best I can, setting an example for how questions should be answered and list members should act.  Of late, I’ve been too swamped to offer more than token participation on the list, which is why I just yesterday selected four list members to be moderators.  They’ll be helping with administrivia, but more importantly, will be helping to keep things on-topic and civil, although I honestly don’t expect them to have to work very hard at that last part.  Heck, I’ve been an absentee dictator for a couple of months now, and things have stayed mostly on-topic and very civil.  Basically, having put the effort into rolling this massive boulder in a certain direction, it kept going that way even when I stopped actively pushing for a while.  Just recently, things have started to deteriorate a bit.  That was a major impetus to get off my keister and pick some moderators.

So I guess my point is that there’s more to a community than its members.  The founder’s influence is strong, and if the community has someone (or several someones) actively in charge who can make my-way-or-the-highway decisions but still be reasonable about them, it can be kept very nearly flame-free.

Still, some of the ideas Clay discusses would be very useful, even in an already-civil environment like css-d.  He proposes, for example, adapting features of the Slashdot karma/moderation system to mailing lists.  In the css-d context, such a system would probably function more like the eBay “Rate This Seller” feature; for us, it would be a “Rate This Member” mechanism that could communally identify those who are helpful, knowledgeable, and so on.  Similarly, a “Rate This Thread” could be used to identify topics of interest as well as topics that nobody wants to hear about.  (Like font sizing.)  I believe that by getting distributed, evolving community input of that kind, the list would be strengthened and enriched.

It would be interesting to add such features, but in the current environment, I don’t see a way to do so—and, let’s face it, I’m not the world’s most proficient programmer.  Right now it’s mostly something to keep in mind for the future.  Especially if you happen to be working on mailing list software.

S5 1.1a2

I’ve posted an update to the testbed file that incorporates the new font-scaling routines from Michaël, and also a slightly corrected version of the internal-link slide routines contributed by Henryk Plötz back in the 1.0b2 days.  These routines all seem to work fine, except the internal-link routines don’t seem to work at all in Safari.  I tried several times to fix it, but I can’t figure out the problem.  So fixing that is now on the to do list.

Speaking of which, here’s the current to-do list for S5 1.1, categorized by their importance.  Any of these are, of course, subject to modification, deletion, and so forth.

  1. A way to trigger simple in-slide changes by hitting “next”.  For example, having a list of bullet points appear one at a time as the space bar (or other “next” action) is hit, and then moving on to the next slide.
  2. The ability to cleanly list multiple authors in the metadata.  I’ll get back to this in just a minute.
  3. Better, possibly more dynamic, theme selection.  I don’t know how yet, nor am I sure how it might impact the outline/slide show view toggling.
  4. A way to choose whether to show/hide all of the navigation controls, or just the menu.  Ordinarily, I’d say “do it in the CSS!” and you can in fact do that right now… as long as you don’t care that the behavior won’t be quite right in Internet Explorer.  The problem is that I’m not quite sure how to manage this in a fully cross-browser fashion, short of scanning the CSS files for certain rules, and firing JS based on that.  Which, frankly, sounds kind of ooky.  Adding that information via a meta tag doesn’t seem like the right answer, but maybe I’m wrong.
  5. A way to indicate the target resolution in the CSS, so that the scripts can use that for scaling purposes (thus making the scaling more intelligent).  I’m not really sure this is needed, and I’m open to being convinced one way or the other.

If there’s anything missing, let me know.  Also feel free to comment on what you think of the above plans.

Now for the metadata situation.  As I understand things, having read RFC 2068, you can have multiple HTTP headers that share a name so long as they’re interpreted as a comma-separated list of values associated with that name.  (Apologies if I’m mangling terminology, but HTTP headers aren’t really my thing.)  So given the following:

<meta name="author" content="Eric Meyer" />
<meta name="affiliation" content="Complex Spiral Consulting" />
<meta name="author" content="Joe Public" />
<meta name="affiliation" content="ConHugeCo Corp." />

…this is an equivalent construction:

<meta name="author" content="Eric Meyer, Joe Public" />
<meta name="affiliation" content="Complex Spiral Consulting, ConHugeCo Corp." />

I find this to be a long way from ideal.  In addition, since commas are the default value separator, if I understand the situation correctly,  I can’t really do something like this:

<meta name="authors" content="Eric Meyer, Complex Spiral Consulting; Joe Public, ConHugeCo Corp." />

…because that ends up as equivalent to:

<meta name="authors" content="Eric Meyer" />
<meta name="authors" content="Complex Spiral Consulting; Joe Public />
<meta name="authors" content="ConHugeCo Corp." />

That’s even further from ideal.  So here’s my current thinking for a way to represent multiple authors and affiliations:

<meta
 name="authors"
 content="Eric Meyer - Complex Spiral Consulting, Joe Public - ConHugeCo Corp." />

Anyone have a better idea than what I’ve proposed?  I’d love to hear it.  As part of said proposal, please keep in mind possible expansion of the information carried in the meta element.  For example, titles might be added, which in my current thinking would go like this:

<meta
 name="authors"
 content="Eric Meyer - Principal Consultant - Complex Spiral Consulting, 
          Joe Public - VP of IF - ConHugeCo Corp." />

It isn’t pretty, but it conforms to my understanding of meta value syntax.  As I say, I’d be very happy to be shown a better way of forming the meta values.

September 2014
SMTWTFS
August  
 123456
78910111213
14151617181920
21222324252627
282930  

Archives

Feeds

Extras