Kindle Versions

Shelley Thu, 01/29/2009 - 10:01

On Groundhog Day, I'll have had my Kindle for a year. I've been working on an anniversary review of the device, which will get posted either to the Frugal Algorithm or Secret of Signals. Or perhaps a bit in both, not sure.

The buzz about the Kindle now is that a 2.0 version is coming out, February 9th. I imagine a new version is likely, but contrary to what people have been saying, there has been more than one Kindle variation released in the last year.

Currently, there are Kindles running the following operating system versions: 1.04, 1.08, 1.1, and 1.1.1. Amazon has stressed that all provide the same functionality. The only thing to account for the difference, then, is variations in the device. Not a simple swapping of parts, either, because one doesn't need to update an operating system when one swaps identical parts.

I have a 1.04 version of a Kindle, and must admit to some curiosity about what improvements went into the 1.08 and 1.1 models. I know that one always takes risks buying version 1 of anything, but I don't think I've ever seen a case where an item's internal architecture has changed three times within one year. Changed enough to force a new version of the operating system. At a minimum, I have to wonder what will happen when new software functionality is rolled out. Do we 1.04 owners get the same goodies as, say, 1.1 owners?

To add further to the confusion, some people have reported in the owner forums seeing an OS version of 1.2 in their devices, and there are differences with this OS, but Amazon has stated this operating system has not been released. So rumor runs rampant in the forums, because we have no other source of communication about what's happening with the devices. To be blunt, Amazon does not communicate with Kindle owners.

Regardless of lack of communication, and despite being an "old" Kindle owner, I do still like my device, though I really wish we had folder capability. However, I'd really rather that Amazon support ePub, and release its AZW format to other ebook readers. And I'll have more to say on this later, too.

Hiring the Critic

Shelley Wed, 01/28/2009 - 14:19

If I had known Sitepoint would be hiring I may have held back from telling the lead designer that he's full of bull. He was full of bull, though, with his exhortation to XHTML users to grow up. Still, another opportunity lost.

There is no room in this economy for the critic. At least, not unless one is already employed. The wind is blowing towards sweetness and light. Desperately blowing, caught up in the maelstrom of fear and uncertainty.

What should I do? Continue to criticize, until I can no longer afford my web space? Or shut up, and hope that someone safely employed takes the time to respond? I guess I pick my battles. Perhaps only criticize those who can't do me any good, or have no power.

Fah, I sneer at my own words.

8-track

Shelley Sun, 01/25/2009 - 17:20
8-track

HTML 4 is to markup...

Shelley Sun, 01/25/2009 - 17:17

In an interview at WebScienceMan titled, XHTML Users: Grow up!, the interviewee, Sitepoint's Tommy Olsson answers a question as to whether he likes XHTML with, Grow up! :) Seriously, XHTML is long dead, due to a decade of horrible abuse. Not even the bleached bones remain..

Mr. Olsson believes that we should be using HTML 4, strict HTML 4, because HTML5 is still a bit of whimsy, and XHTML is a pile of dead bones. As I wrote in comments, HTML 4 is to markup, like 8-track is to music.

8-track cartridge

The Frugal Algorithm

Shelley Sun, 01/25/2009 - 15:16

My WordPress site has now gone live: The Frugal Algorithm. In the opener I wrote

We are too often seen as consumers in a disposable society, whose primary interest is what new toy to buy, and how much garbage we generate. When faced with difficult times, we buckle down reluctantly, anxiously waiting when the times are better and we can return to a time of “prosperity”, prosperity in this context meaning buying more stuff. Our societies are based on the concept that worth is measured in goods, and the ultimate health of the collective is based in gross national product and balance of trade. We work to buy, and we buy to work.

But what if we broke the cycle?

Other writings:

As stated, The Frugal Algorithm is based in WordPress, while my other sites stay at Drupal. The theme at Frugal City is a modification of the WordPress theme, Barecity, which I thought was an appropriately named theme. It's minimalist, much more so than my other sites. Again, though, a minimalist design fits the site concept.

I did have to modify the theme to make it XHTML compliant, and WordPress isn't as XHTML friendly as Drupal, but the differences just keep me on my toes.

The site is actually more of a celebration of the times, then not. I'm not downplaying the unemployment and the real fiscal worries we all have—heck, I'm teetering at the edge of the abyss myself. But in my readings about the Great Depression, one thing I noticed is that the people during the 1930s seemed to be more capable of directly facing the troubled times. Today, we're more likely to put our hands over our ears and hum "LaLaLaLa!". We tell ourselves and each other that we're trying to maintain a positive attitude but what we're really doing is denying reality, and in doing so, denying others their reality. Life is just a bowl of cherries.

Not long ago, some happy soul pontificated that the only reason people don't have jobs is that they weren't really trying. Not really trying...Last week, a company was looking for 100 new employees in the St. Louis area, and held a job fair. Over 3,000 people showed up at the fair. This is addition to a couple of thousand other applications given online. It worked out to 50 people applying for each open position.

Facing up to the times means being aware that other people may be struggling. It means learning how to manage when you're struggling, yourself, or how to live so you don't get to the point where you're struggling.

The Frugal Algorithm isn't a doom and gloom site, but it's not a haven for the Shiny, Happy People, either. It's a way for me to work through my fears, and maybe help others do the same. More importantly, the site's focus is on recognizing that a person's value is not based on the toys they own or the money they make; to find something real, inside.

Pinky and the Markup Brains

Shelley Wed, 01/21/2009 - 10:03

What ended up being the ultimate irritation of my brief foray into HTML5 land, is that I found out, after careful perusal of my original use of RDFa, that I wasn't using it incorrectly. However, by the time I got through listening to all the arguments, back and forth, and round and round, I was beginning to doubt whether an angle bracket really looked like < and >. I am correct, aren't I? These are angle brackets, right?

Of course not. I call them angle brackets, but others call them diamond brackets, and I'm sure someone else, most likely from the UK, calls them elbow brackets or the Queen's brackets, or some such thing.

However, the back and forth, and round and round, wouldn't be an issue, could even be a journey of discovery, if it weren't for the arrogance of some of the participants. Or, what I perceive to be arrogance. Variations of, "But that's wrong and here's why", followed up with references to other specifications that hurt, actually physically hurt just to look at, given in a tone of, "How could you think otherwise?" Or responses based on some absolutely obscene piece of markup minutia, repeated over and over again, in attempts to hammer the point home to we, the seemingly dense as bricks.

The end product of such discussions, though, is that people like myself flee the discussion—literally flee, as if the hounds of hell were chomping at our butts. The downside of running away, though, is we're left feeling that we have no input, no control over what the web of the future will, or will not, allow. That the web of the future of the web is designed by and for the web designers, and not thee and me.

The real problem, though, has less to do with communication style, and more to do with differing levels of expertise and interest. People like me, who are consumers of a specs, are mixed in with people who create the parsers and the browsers, and live and breath, eat and sleep this stuff. What else can we, the consumers, do, though? There seemingly is no way for those of us, on the dumb side of markup, to communicate our concerns, wishes, and desires to the other side. But when we do venture into the lists, we are quickly overwhelmed with the specs, the references, the minutia. Our interests get lost in the fact that we don't have the language to participate. Worse, we don't have the language to participate in a field notorious for being both competitive, and impatient.

Unbeknownst to ourselves, we have become Pinky to the markup Brains.

So we consumers flee the lists and leave them to the developers and designers, and the end result is that we have specifications, and eventually implementations, that, well, frankly, scare the shit out of most of us.

Don't believe me? How else could you explain the Yellow Screen of Death that appears whenever you make a simple mistake in markup for the post you're writing? Not a helpful error, or an error that gently points out where and why the problem occurs; an error that tries to work with you to correct the problem.

No, it is an ugly error, an angry error, with red on yellow, that screams, "Bad, Shelley! Bad", before it invariably trails off to uselessness on the right side of the browser. You don't think an actual person like you and me would have designed a specification that encourages this behavior, or a browser that implements it, do you?

The true irony, though, is when you do voice concerns, or criticism, you're typically met with, "If you want something, you need to participate in the email lists working on the specifications", and the cycle begins anew. Narf.

update Wow, speak of the devil. What will Mozilla do with that feedback? Why, conquer the world, of course.

Brain!

The SVG Feed

Shelley Mon, 01/19/2009 - 10:36

I had originally created a Planet SVG in order to bring together a feed of SVG items. Once the SVG IG created Planet SVG web site, for all things SVG, I redirected planetsvg.org to it.

I still wanted a feed of SVG-related items, so I created the SVG Feed. Currently, the application queries SVG feeds once a day, including my own Delicious SVG-related feed. The latter was my way of ensuring that items related to SVG that aren't accessible via a feed, or the related feed isn't specific to SVG, get included.

The SVG Feed has it's own feed, and uses Planet and Venus software. It only updates daily, as there are not enough items for more frequent updates. If you know of an SVG feed that should be included, send me an email.

And with all that

Shelley Sun, 01/18/2009 - 16:37

And with all the unpleasantness this weekend, including a comment breaking my XHTML, captured for posterity by the playful, puckish, Anne, I find that I have misunderstood one key element of the RDFa specification, and have embarrassed myself greatly.

Why is every time I touch anything to do with the W3C or associated mailing lists, I always come away feeling like the idiot child who has just wasted the time of her elders? It has gotten to the point, where I don't want to write anything about technology online.

Now, I have to re-visit my XHTML formatting for my comments, for yet another use case that is slipping through the filters.

update Another set of test cases bites the dust. I now have two modules, HTML Purifier and htmLawed implemented, in addition to the built-in URL converter and automatic line break functionality. The order these are implemented is important and the following seems to create a compatible effect: HTML Purifier, htmLawed, URL converter, line break. I'll have to do other testing, but two particular use cases that came up yesterday—yes, two— both seem to be trapped with these changes.

second update Based on request from from the htmLawed creator, I attempted to reduplicate the original errors. One was quite simple: the use of <self-close /> caused the Drupal built-in HTML corrector to over correct, adding a </self-close >. I'm not sure why I had the built-in HTML corrector active, anyway, as it does conflict with htmLawed. Removing it removed the problem.

The second test case didn't get corrected by htmLawed, when I tested with the original comment, so I added HTML Purifier. However, when I went to duplicate the test case, I couldn't, so I had documented the test case for duplication incorrectly. I've since turned off HTML Purifier, and if the case occurs again, will leave it to show the htmLawed creator. It doesn't hurt to use both modules, and I only use them with comments, but if I don't need two, I'd rather not use two.

Respect

Shelley Fri, 01/16/2009 - 14:35

I have spent too much time worrying about specifications managed by people who, frankly, don't have a lot of respect for what I have to say. I am not a browser developer, specification author, nor do I fit within the narrow parameters of "people who are seen to be contributors".

Years ago, I defined the term Coders-Only-Club, to designated the seeming feeling of being an outsider, unless one acts a certain way, or does a certain thing. I can definitely say unequivocally that writing books or weblog posts does not ensure entry into the Coders-only-Club, or perhaps I should term it, "Contributors-Only-Club". To be honest, writing simple tutorials or examples, helping people, or answering questions doesn't gain one entry, either.

What's absurd about the whole thing is I'm fighting for something I don't really need, because I do have viable alternatives I can use with my own work. I deliver every page at my web sites as application/xhtml+xml, which gives me singular power to accomplish wonderful things. I doubt, very much, that any browser is going to drop XHTML support for many, many years to com, so I can continue to incorporate SVG, or RDFa, or any number of new vocabularies that haven't even been invented yet.

Frankly, I'm just wasting my time worrying about things I can't change.

HTML5: Put Up or Shut Up

Shelley Fri, 01/16/2009 - 12:34

Sam Ruby

I question the presumption implicit in the notions of “the” editor, and “the” spec. I reluctantly accept the notion that any individual spec development process need not employ processes requiring consensus or voting, but I reject any implication, however subtle, of inevitability or entitlement.

Simply put, there needs to be a recourse if a person or a group disagrees with a decision made by the editor of the WHATWG document. That recourse is forking.

I realize that that is a very high bar, and will say that is intentionally so. Simply put, specs don't write themselves... I don't care how good you think your idea is, either you need to step up and directly write the spec text yourself, or accept that you need to be persuasive.

Quite simply, that is the most absurd set of statements I have ever read. What Sam is saying, if you don't like it, fork, or shut up.

Have to be persuasive? How can one be persuasive when there are underlying biases and prejudices in play that makes it impossible to ever...ever persuade the gatekeepers to change their mind? Or even open their minds?

So the alternative that Sam allow us, is to fork the entire HTML specification. Contrary to some people involved in this discussion, most of us are not employed by large corporations and can spend all of our time reading mailing lists or participating in specification work. Most of us have to do other things in order to pay the rent, or buy food.

But we are still dependent on the same specifications, still concerned that what comes out of a group such as the HTML5 working group is the best specification for as many people as possible—not just representatives from one or two companies who control the HTML5 specification development with a fist clad in an arrogance as dense as the thickest iron.

As for contributing to the group, the HTML5 editor did put something out, recently, on the mailing list about other editors. The requirements demanded for these voluteers were such that few of us could even consider applying. I can't guarantee I have 20+ hours to devote every week. I can't guarantee that I can fly to meetings with other editors, no, not even once a year. The most I, and others like me, can guarantee is that we would try our best, but keeping the roofs over our heads has to be our first priority. When was the last time the powers-to-be behind the HTML5 effort opened their windows and got a good whiff of our troubled times?

I also resent the assumption that those of us not directly contributing to the editing of a specification are not contributing. Contrary to what Sam seems to believe, we don't need to be a member of a specification group, or an editor of a specification, to contribute to the overall success of the specification. People who write about the specifications, in books or articles, or who provide tutorials, example applications, libraries, help others—we contribute just as much as those who formally create the specs. The only difference is that our names don't get listed, we rarely get credit, and evidently, according to Sam, we shouldn't express any concerns, or frustrations, either.

Well, perhaps that is the way of the world for HTML5, but thankfully it hasn't been that way for any other web specification I use, including XHTML, CSS, RDF, SVG, and so on. Oh, we still may not be able to influence these specifications, but I've not seen any of these groups give so much power over the direction of the specifications to so few. I've not heard once, from any of the people behind the specifications, to either put up, or shut up.