Older blog entries for Ilan (starting at number 140)

I'm not too sure how I should approach the topic of examples for the AUHDL. Certainly the license should contain the suggestion (but not the requirement) that three examples be provided for every variation of every type of procedure. I'm very passionate about examples; the lack of examples I've faced in so many math and science textbooks is the main contributor to this sentiment. Anyhow, I'm not sure whether prohibiting modifications that remove examples would be too impractical in some cases.

But sometimes the shit just seems
everybody only wants to discuss me
So this must mean I'm dis-gus-ting
But it's just me, I'm just obscene

My last post was really irresponsible.

I forgot to add man pages to the AUHDL's list of forbidden doc formats. How could I forget the bane of every new user to linux who tries to understand what's going on? How could I forget the category of documentation that gives us the 'M' in 'RTFM'? How could I forget the one?

I should really be smacked on the bottom for such a careless omission.

I believe in freely distributable and modifiable documentation so long as the end-users' Freedom To Use Their Computers is not violated. The freedom to enslave end users in a world of confusing documentation is not a valid freedom.

Dear diary,

here's what I've written so far of the AUHDL. I hope to get more down soon.

The Anti-User Hostility Documentation License.

Traditional open-source and free software documentation is meant to deprive an end user of their basic freedom to understand how to get work done with their software. This deprivation of freedom is distilled into a form of oppression, where the only answer to a question born of confusing documentation is "Read The Fine Manual". Further silliness ensues when a world ensconced in 32-bit color and interactive multi-media is eschewed for a world of text-only documentation, whose only attempt at graphic amelioration is pathetic use of more text. We of Clarux feel that the freedom to oppress end-users is not a valid freedom.

It is painfully clear that those who feel it is acceptable to produce documentation that oppresses end-users either through its lack of clarity, lack of examples, or simple lack of existence clearly do not deserve to use, distribute, or take credit for documentation created by those who feel differently. It is the goal of the Anti-User Hostility Documentation License to promote open, accessible, and understandable documentation and thereby create a more open, accessible, and understandable world of technology.

Terms:

1. All documents produced under the AUHDL must have at least three graphic elements. A graphic element is defined as a diagram, drawing, or a computer monitor screenshot. Any modification to a document protected under the AUHDL that reduces the number of graphic elements by less than 3 is prohibited. By July 1, 2003, the requirement for graphic elements will be extended to the use of at least 3 colors. Modification of a document protected under the AUHDL that reduces the number of colors used for graphic elements by less than three is prohibited.

1.5 While not enforced, it is encouraged that writers of documentation licensed under the AUHDL make their documents accessible to users with visual impairments. It is suggested that authors do not rely solely on the use of the colors to convey relationships, as a significant population has red-green color blindness. It is also suggested that the navigation and display of relationships between pieces of information accommodate blind users.

2. Use of ASCII or Unicode text as a substitute for graphic elements (the practice informally known as "ASCII art") is hereby prohibited from any document protected under the AUHDL. Any modification of an AUHDL document that includes "ASCII art" is expressly prohibited.

3. Any person, company, or entity that wishes to distribute or link to documentation licensed under the AUHDL license must agree not to distribute, link to, or post on the internet the following documentation formats:

a) HOW-TO's.
b) TexInfo
c) Any text-only document.

I've still got bunches to add, but it's a start.

Started writing down the Anti User Hostility Documentation License (AUHDL) after months of thinking about doing it. Every day now I tell myself "Ilan, either shut the hell up or do something about it". So I've started to do something about it.

Writing things down is good.

Dear diary,

I've been thinking a lot about my licenses to deal with linux's usability problems. I should stop thinking about them and get them down on paper or some kind of storable format. As the needlepoint in Marty Hansen's office once said "there are no good writers. Just good re-writers". I can always re-write them and clarify points later on. The important thing is to get the first drafts done.

I won't we able to post any long meaningful diary entries until my cog psych exam is done on tuesday. But I must say, Joy of Tech has been in rare form the last several days.

Since the last time I've posted, I've brushed up on my xml-rpc so I can working on the syncing part of my Zaurus diet program. As the program is written in python, I'm using the xml-rpc python module, though it would be kind of cool if there was a whole application syncing infrastructure for the zaurus that used the DCOP xml-rpc functionality (I'm buzzword compliant today); that way I wouldn't have the overhead the python interpreter running in the background. Once I get the syncing worked out, I'd like to write the desktop software in Java to make Zaurus syncing truly cross-platform.

As for other zaurus-related things, I've been trying to think of new and better xml file formats the zaurus could use to hold stuff like dates, addresses, etc. The fact that the current file formats from Trolltech really don't have much in the way to support two-way syncing sucks. The fact that the XML tags/attributes are impossible to understand and make sense of sucks twice as much. I suppose I *could* look at their code, but my feeling is that any xml file format that forces you to look at the code to understand it is a file format crying out for reimplementation.

Quote for the day:

"It sounds like a Nostradamus Prophecy-'A team from the south will win a hockey championship' "--Andrew Turnier

raph's post got me thinking about the reports I've also heard that the font in OS X is a pain in the ass to read.

I have serious suspicions that many of the complaints over the font rendering in OS X are the result of two things:

  1. The decreased contrast of the outlines of the letters increase visual search time.

    The longest part of the secadic eye movements that are used in the visual searches done on text is dwell duration, which is partially governed by the ease of information extraction, ``which is often influenced by stimulus quality(e.g. in target search, longer dwells on a degraded target).'' (Wickens, Gordon, & Liu, 1998).

    I'm actually getting the information in the above paragraph from the textbook from my human factors course this semester. (I like it a lot. Who thought studying could be so much fun? One should follow their passions and do what they love to do. Preferably for a large sum of money, if possible.)

    My point--ridiculously anti-aliased text is a ``degraded target'' and thus takes longer to perform a visual search. And this would especially suck for older adults like Doc whose visual search capability is already fairly degraded.

  2. The reports of increased eye strain are the result of the brains futile and automatic attempt to compensate for distance.

    When the brain sees text with a reduced contrast and the appearance of blur, visual accomodation (the eye's lens moving to accomodate for distance) kicks in automatically. In other words, ridiculously anti-aliased font tricks the brain into thinking the font is at a different distance than it really is, and the muscles in the eye are constantly trying to adjust the lens very so slightly in the futile attempt to bring the blurry text into focus (which of course never happens). Given that some people feel okay with the extreme anti-aliasing, it might be possible that the brain eventually adapts and quits trying to bring the text into focus. It would also be fascinating to see whether screwing around with the perspective to make the ridiculously anti-aliased text appear to actually be a different distance than the rest of the screen would eliminate the eye strain. Making a menu selection look farther/nearer than it actually is would be a less than adequate solution. But it would be interesting to see if it could be done.

Some of this (mostly #2) is somewhat conjecture right now. But I suspect that if I could get my hands on an oculometer and a bunch of guinea pi...er..subjects and sit them down in front of such environments, I could easily prove both of these conditions to be true.

131 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!