bpm's Operations Room

Browsing the skins gallery with the icon chart open in another pane, you see the whole array for any skin you click on

Here are three sets (pictures inserted for a quick look, and a couple attached for unsquashed viewing - click the links to see them at full size):

Tango CL at 16x16


Handmade at 26x26


Classic at 26x26:


Making the chart as a learning experience
A project like this, taken on by someone who basically lacks the required skills, will if done right teach a lot of lessons - as the principles and methods that go into the ideal form are recognized, one by one. I've been through six seven epiphanies with this chart. Here's that story - because what were lessons for me will be lessons for many, if noticed - but it's easy not to take them in, and gain little. And moving to a larger field of view, there's a seventh epiphany - which you can take or leave.

I started with what there was before - Scipio's live icon chart. This has important virtues - it's a comprehenisve live list - but formatted as a table with one icon per line, it's anything but dense: one has to scroll through 24 screens to see all the icons. I've always been concerned about cognitive ergonomics -information density, scope of view, and glanceability. So it was natural to modify that chart for my own use. Packing it as densely as possible while keeping names displayed gave five icons per line, and a several-screen chart - and there the matter rested, for about a year. But the screens were still mostly text and empty space (columns being sized for the longest caption)... this is HTML, right? Active, able to show what you need when you need it, hide it when you don't. First epiphany: one could convert the icon names into HTML titles - hover the icon to see the title, in a tooltip and in the status field. That gets the icon count up to 25 per line, which puts the lot of them comfortably on one screen. (First posted version.)

Next, I realized that, using HTML, we don't need to decide how many go on a line, and actually shouldn't: we can abandon table layout, and let them float. They'll flow into available space, and never require horizontal scrolling. So I stripped out the table, and let the divs float (version 2; presented in three variants, one for each of the standard icon sizes).

Feeling pretty good, having contributed a basic resource. However, as often happens with AyushJ around, he was provoked to go one or two better. He posted a form which uses "-o-skin" as the size - which means "whatever it is in the skin" (resolving the puzzle of how Scipio had done that). He also used XML to eliminate repetition in the code - nifty stuff: a template, and a list of things to which it should be applied - it cut file size to a quarter of what my more pedestrian methods require. Finally, after some thought he programmed the icons to put their names on the clipboard when clicked. Here's this elegant variant: AyushJ's name-writing chart. (Nov 2009: name copying, for some reason, no longer works.)
His list however is not in alphabetical order, so finding icons by name becomes a problem.

Ayush also pointed out that my multi-version approach could be bettered by switching to a single, multi-mode file. The only differences between those files had been a couple of numbers, specifying icon dimensions; with CSS (Cascading StyleSheets), you can move those tiny differences out into style files, called from within the main file. Opera can handle this - it puts the names of the styles available for use on the Style menu (a submenu of view). So... version 3 - using that standard style-switching system, which you can still see in the non-javascript form of the chart. With that open, click View, then Style - and look right at the bottom: there are your options:

• 16-pixel: what's used on menus. (With the icons so small, there's lots of room - so I show the 160 or so Box and Tile icons (at their native size) in this view, but not any of the others.)
  
• 22-pixel has been the Opera standard.
  
• 32 pixel is the jumbo option.
  
• Native shows you the images straight up, life-sized - not expanded or reduced. Some surprises here: a few giants among the minnows (what is going on with that Thumbnail Busy Image?) This gets a bit disorderly as the float patterns are disrupted by the whoppers (actually it's a good little demo of how float works).

But there was a drawback to this: it made the file dependent on external helper files (the four tiny stylesheets), stored on Opera servers. It's similar to how images are handled - but Opera's site has a lot of downtime, and I wanted the chart to be reliable... a user should be able to store it locally, and use it without a connection. So I had the idea of including a popup help page, with listings of the stylesheets and instructions for setting them up (version 4).

That lasted a day - and then, puzzling over the strange awkwardness of this CSS system - which makes a messy multifile system out of what one would at least sometimes much prefer to have as a single document - I wondered what would happen if, instead of the URLs of actual CSS files in the style links, one smuggled in the content of those files, as data URLs. Pseudofiles, you might say, and pseudolinks: tricking a clumsy system into being less clumsy. I tried it - and it worked! (Version 5.) That took the chart back to being a unified, portable file - and the popup help became nonessential, mostly a version history whose motivation is learning benefit (version 6). Final form? Well - one always thinks so for a while...

But that menu approach - it's a contortion, a violation of paradigm. Document controls make sense on the document - having document features which show up only on a browser menu - out of sight, nested inside another menu, accessed through the menu bar - what is that about? So the next desideratum was simple, familiar on-page buttons to switch icons sizes, instead of the Style menu.

Studying this, I kept finding that all the simple routes were blocked. I seemed to be up against something fundamental in the system. To issue the command, "let all the icons now be 22 pixels high," I needed to use nouns with verbs for which they were not permitted. It turned out to be possible, but not until I understood the cul-de-sac I was trapped in well enough to back out.
To put the matter in the jargon of CSS and javascript (skip this list if you don't know them), the prohibited simple things which would meet the need were:

• a button whose action was a GetElementsByClass operation; or
  
• a button whose action was to invoke or define a stylesheet: onclick=document.addstyle='medium'. (Why not? A stylesheet is a document feature, which has a status of being active or inactive - exactly the sort of thing a button can toggle - why won't they let me do it?);
  
• a button whose action was to modify styles as elements of the document: GetElementByID(iconstyle).innerHTML='height:16px;width:16px' They ARE elements of the document - strings of characters, meaningful code - and commands which specify substitutions of character strings have been developed; why on Earth not allow them to be used simply everywhere?
  

Why don't these things exist? Because systems evolve chaotically - and lock in to patterns which can only with difficulty and effort be changed. Paradoxically, a terrible system is more likely to get fixed than one which is viable if you endure the pain of mastering its idiosyncrasies. Like organic evolution, things happen only if each step along the path is worthwhile for those who have to make it. Those who have mastered a cramped semi-coherent language have no great need to make the system more regular - more sensible and transparent. Look at the spelling of English: relics of Medieval pronunciation which now bedevil every schoolchild. Debris of a process of historical development, a path chosen step by step and not with a clear view of a final destination. Systems with no-one in charge.

So: in this cramped world-as-it-is, the insights which make things possible are often workarounds for random systemic defects. Like a lawyer, you have to learn how to say some simple thing that needs to be said while obeying the weird strictures of a fundamentally unjustified discipline - with all the difficulty coming from the randomness and incoherence of the rules you have to follow. (I've written a few patents; I know what I'm talking about, in terms of arbitrary strictures of language which absolutely must be accepted and obeyed.)

The bind in this case is that CSS can assign styles to types of things statically, and javascript can change the properties of single objects dynamically - but neither allows you to change type properties (such as size of all icons) dynamically - in a direct way. (Don't imagine that there's a reason for this - it's not like that. It's just what we have to work around.) And the insight which comes as a breakthrough to the stumped coder is that there is a maneuver which will always work - as one can be sure, because one can figure out its principle. It relies on the fact that CSS styles of small objects can depend on the class of larger containing objects. Therefore, changing the class of a single encompassing object (right up to, ultimately, the whole page) can actually toggle all the properties of everything within it - and therefore any desired subset of them. You give a classname to the desired page state; you write a stylesheet which states that the icons are the size you want, if the page is of that class. Then you can issue the javascript command which says, "switch the page to the 22-pixel-icons class." You've obeyed the rules, but nonetheless dynamically changed properties of a type of thing. Call it the Principle of Type Switchability Via Container Class Switch.

Is it just a stupid word trick? Basically, yes. It's jumping though the hoops - learning to turn away from the direct and familiar way of expressing something because that hasn't been implemented. (And being clear on the essential triviality of the skill is vital if one is to make sense of the system of which we are all parts.)

That clear, you can do anything that people do with external stylesheets. You've taken the Native stylesheet, prefixed "#document.Native" to every line, and stuck it in your document - and you can have as many prefixes as you like, and thus fuse as many external stylesheets as you like into one internal stylesheet, each a document mode toggled by a javascript button.

So it's a hack, a detour around a senseless obstacle - and most people will never really be clear on that. There's nothing intrinsically hard about the thing that needs doing, or about specifying it - any child can explain it to any other child. Furthermore, any child can understand this point that these puzzles we have to solve, these requirements for unobvious maneuvers, are random artifacts of history. The story of chaotic processes establishing kinked paths and obliging people to master the kinks is a clear story, if it's told properly. We're confused - but that's a mode, and not essential nature. The randomness, the lack of meaning at a certain level, is meaning at a higher level - is the big picture and has to be clear - otherwise you're hesitant, picking your way through a foggy world whose causalities are in some mysterious way beyond your powers of scrutiny.