brian will . net

The Linux community is often accused of being poor at catering to non-expert users, but this is a misdiagnoses. Contrary to myth, the community is not full of old Unix beards demanding the rest of us master perl before they give the rest of us the time of day. Surely, many Linux users lament that more people don’t see the virtuous ways of the command line, but very few of them still refuse to accept that most people just have better things to fill their heads with than cryptic Unix utility names, parameters, and Bash syntax. And this acceptance is not just reluctant: there are large projects (GNOME and Ubuntu first among them) whose primary mantra is to make Linux bare bones simple enough to bring naive and non-programmer users a painless Linux experience.

The real problem with the Linux community is not that they disregard non-expert users but that the Linux community fails to account for the sliding-scale of expertise in between ‘competant Linux installer/admin’ and ‘Aunt Tillie who thinks that the blue E is the Internet’. (“Aunt Tillie” is the name of the naive Linux user in Eric Raymond’s essay about Linux usability, The Luxury of Ignorance.)

[...]

How does one make sense of Java’s version history for learners? The full story is at http://en.wikipedia.org/wiki/Java_version_history, but here’s the brief version:

First be clear that that there is only one Java language—one set of syntactical rules for how to write Java code. This set of rules has grown a few times since Java’s introduction in 1996, but valid Java code written in 1996 will still compile with today’s Java. However, the standard Java libraries have also evolved over the years, and some parts of the library have been deprecated (meaning you shouldn’t use them in new code you write because they are flawed and may be completely removed in future versions), so old code may need to be reworked to use modern libraries in place of deprecated ones.

While there is only one Java language, there are several implementations of the language, meaning there are different compilers, different JVM’s (Java Virtual Machines), and different implementations of the libraries. These varying implementations (mostly) all conform to the Java standards, but some have extra features and some have performance advantages over others. The most widely used Java implementations are from Sun, the originator of Java. Recently, Sun has begun releasing its Java implementation under the GPL (Gnu Public License), a free / open source license.

Java is, in truth, a standard and not just a particular line of software downloads released from Sun. For simplicity, though, we’ll only consider the Sun releases and their terminology, as Sun’s Java is the most popular implementation and the one learners should use.

Standard Edition (SE) vs. Enterprise Edition (EE) vs. Micro Edition (ME)

Java comes in three “editions”, which, strictly speaking, are specifications, not actual implementations of a JVM (Java Virtual Machine) and Java libraries. In practice, though, the terms are most commonly used to distinguish between the three Java implementations freely downloadable from Sun.

• SE is the baseline JVM and libraries. This is the edition used by most PC end-users.
• The JVM you get with EE is one and the same with the one in SE, but EE adds a large number of libraries for server-oriented programming. It generally never hurts to download and run Sun’s EE Java distribution, but as a learner, you’ll likely never use the EE libraries. I prefer to browse the SE documentation so I don’t have to wade through EE stuff I never use.
• ME is Java adapted for resource-constrained (i.e. low memory, low power) devices, e.g. cellphones and PDA’s. Because of their typically low storage and memory capacities, such devices can’t afford to have all the libraries found in SE (and certainly not in EE). Small devices differ significantly from one another and so Sun leaves it up to device makers to offer proper implementations of ME for their particular platform. Sun has an ME reference implementation that runs on PC’s which is used for software development (just because you’re writing software for a cellphone doesn’t mean you want to write it on a cellphone!).

Java Development Kit (JDK) vs. Java Runtime Environment (JRE)

On PC’s, you have the choice of using Sun’s JDK or the JRE. The JRE, meant for end-users, comes in only the SE flavor and contains the JVM (Java Virtual Machine) and the SE standard libraries. The JDK comes in the three editions and includes not just the JVM and libraries, but also development tools, including javac (Sun’s java compiler), so this is what you’ll want as a programmer. If you have the JDK installed, you don’t need to install the JRE separately to run any Java software (though it’s likely your browser will have an embedded JRE of its own). (The term ‘JDK’ is an echo of the more general term ‘SDK’ (Software Development Kit)).

Version numbers

Without getting into the features added by the versions, here at least is the naming history:

• The original release of Java was 1.0, released in 1996.
• Then came 1.1 in 1997.
• 1.2 in 1998 is when Sun split Java into the three editions. Sun began calling this version and subsequent versions Java 2, and so you will see references to J2SE, J2EE, and J2ME (Java 2 Standard Edition, Enterprise Edition, and Micro Edition, respectively). Sun began giving the releases codenames while they were in development, calling 1.2 “Playground“.
• 1.3 in 2000 (confusingly still called Java 2). Codenamed Kestrel.
• 1.4 in 2002 (confusingly still cased Java 2). Codenamed Merlin.
• Sun then decided the version numbers weren’t getting big enough fast enough, so they decided to call the next version, released in 2004, variously 1.5, 5.0, Java 5, or (most egregiously) J2SE 5.0, J2EE 5.0, or J2ME 5.0. Codenamed Tiger.
• Sun finally drops the Java 2 business, deciding that, from now on, the public name of releases will be Java n while the internal development name will be 1.n.0. In late 2006, Java 6 is released, known internally as 1.6.0. Codenamed Mustang.
• Planned for release in 2008 is Java 7 (1.7.0), codenamed Dolphin.

So, in summary, the sequence of most used designations goes: 1.0, 1.1, 1.2, 1.3, 1.4, Java 5, Java 6, Java 7.

As for the feature improvements these versions represent, in general, each release saw bug fixes and performance improvements for the development tools and JVM along with additions to and refinement of the libraries. Aside from these behind-the-scenes changes, Java 5 is the one release which significantly added new features to the language itself, including generics, annotations, autoboxing, enumerations, “varargs”, and the “enhanced for” loop. (None of these features have analogs in PygeonJava, as they are all in one way or another inessential conveniences.)

Here’s the first of a series of posts I’ll write about interfaces.

The use of icons in GUI’s is usually a misapplication of the truism that, ‘simply having users point at the very thing they want is the simplest and most intuitive kind of selection’. The problems are that:

1. Pictographs do not scale as well as text because you can’t alphabetize or do searches on images.
2. As you add more icons to the user’s view, the visual distinctiveness of each icon quickly gets blurry and ambiguous, thus defeating the sole true virtue of icons.
3. Icons are generally not “the very thing” that users are looking for. A pictograph typically provides hints about the thing it represents but is not synonymous with the thing itself.
4. Worst of all, interpreting pictographs is more mentally taxing than reading a word or two, especially when the semantic content is even mildly abstract.

The crux here is that it is far easier for most people to recall the general qualities of a picture—its dominant colors and overall shape—than it is to recall its precise details. Compared to abstract images, images of recognizable objects are much easier to recall details of because we can mentally fill in the blank spots with our assumptions of what such objects look like (so this kind of recall is actually partially false, but it generally works well enough). This explains why most icons in software are so bad: most icons found in software have historically been small, indistinguishable messes that most users just come to think of as abstract shapes even though their designers tried to make them recognizable objects.

Now suppose I know what I want my software to do but don’t remember at all how the interface designers decided to label that function, either with text or an icon. If I’m looking for a label, I have to figure out what words the designers chose to describe it, which often requires consulting my mental thesaurus. In contrast, if I’m looking for an icon, I have to figure out what words the designers chose to describe it and then figure out how the designers chose to represent it as an image. While the number of synonyms for a particular concept can be frustratingly many and elusive, the number of visual representations for a concept are innumerable: even if you narrow down the concrete object(s) being depicted, there are still the variables of perspective, composition, style, and color (sure many real-life objects only come in one color, but many don’t; in fact, looking over the icons in a few applications, I notice a strong majority have basically random color assignments either because of the nature of what they depict or because of the need to make them stand in contrast to their neighbors).

So I’ll posit a few rules about when and how to use pictures/icons:

1. All but the most frequently encountered icons should be labeled by text. Many applications omit text labels because small, unlabeled icons allow for buttons that minimize space use (see Photoshop). This is a poor trade off. First of all, for the issue of image recall outlined above, but also because even the best designed icons rarely communicate their function as clearly as a word or two of text . In fact, the real utility of an icon is that its shape and color makes it noticeable to peripheral vision or visual scanning, so they help users find points of focus and do an initial culling of their possible options; at that stage, however, users have only narrowed their options and prefer the relative precision of words to help them make their final selection.
2. Icons should be simple in shape, distinct in silhouette, have contrasting interior lines, and never use more than two colors.
3. Icons should be as big as necessary to make them conform to rule 2.
4. The number of icons that it is acceptable to use is proportional to how large and distinct they are, vis-a-vis rules 2 and 3. The array of icons found in today’s typical complex apps, like word processors and Photoshop, is too many by a factor of about three.

The next post about interfaces will talk about how the World of Warcraft interface could be applied to the desktop.

Syntax doesn’t matter: any good programmer works with multiple languages over their lifetime, most of these languages expressing basically the same ideas in mostly arbitrarily different ways; any serious student of programming will come to the same conclusion once they learn their third or fourth language.

I’ve seen this in another context, trying to learn Arabic. This Slate article explains the difficulties of this undertaking very well, and it points out what I experienced myself: reading the script is the easy part, and actually not all that hard. Excluding the elaborate calligraphies, English-speaking learners of Arabic should only need a month or two to feel reasonably comfortable quickly identifying the characters and reading them chained together. Additionally, it is surprisingly easy to adjust to reading right-to-left: after a short time, the brain simply makes the switch. (Remembering to open books from what seems like the back takes a lot longer.) Programmers develop this same ‘switch’ when working with different syntaxes.

But syntax, of course, does matter on two ends: programmers have to write in a syntax, and learners have to learn a syntax. Really, when people say ‘syntax doesn’t matter’, they mean that programmers—and those learning to program—shouldn’t think in syntax. This is true, for whatever the syntax, the syntax is not going to change the semantics of what the programmer codes, nor is it going to change the core concepts of a language which the student must learn.

My main purpose in proposing a new educational programming language is to give learners a language that expresses the core features common to modern languages in the syntactically most direct and obvious way possible. This principle should be applied to the libraries of the language as well, so for instance, abbreviations that are non-obvious to a non-programmer must be excised from the language, including the libraries, e.g. the language can’t have anything like C’s “stdio” (“standard input/output”) or “sprintf” (“string print formatted”). (Such abbreviations would be more forgivable if full-names were given in learning materials, but out of the dozens of tutorials and references of the C language I have read, only a couple do so.) Taken individually, shortcuts like these may seem to the initiated like small hurdles, but only because the initiated can no longer see how non-obvious such shortcuts are. The small hurdles quickly add up. Every quirk, every historical legacy, every shortcut is one more thing which at some point is going to cause the learner frustration, possibly halting their progress.

To transition learners from Pygeon (my educational language) into C and Java, it therefore makes a lot of sense to give learners intermediary languages, ones which are as free as possible of the quirks, historical legacies, and shortcuts found in C and Java. Call these intermediary languages PygeonC and PygeonJava (calling them CPygeon and JPygeon would imply we are talking about particular implementations of Pygeon, like with CPython and JPython). Syntactically starting from a base of Pygeon, these languages would be directly translatable into valid C and Java (in fact, this would be the simplest and best implementation method).

To give you an idea, I’ll discuss a few of the syntactical foibles of C and how the semantic content behind the foibles might be more obviously (though likely more verbosely) expressed in a Pygeon-derived syntax:

The first question is whether PygeonC would need to introduce the control flow features of C not found in Pygeon (this includes for, switch, do-while). You can program C just as well without these constructs as you can with them, so it seems OK to omit them. On the downside, not including these constructs delays introducing them to students until they encounter real C, but I feel this is the right choice, as PygeonC is meant to introduce learners to the concepts of C, and these constructs arguably are just syntactical conveniences.

Goto and labels, however, aren’t quite just conveniences, as they often open up significantly different ways of expressing some particular logic, so I feel their inclusion is warranted. More importantly, the fine-grained control offered by goto and labels are in the spirit of C—even though their use is best avoided in almost all cases even in real C. PygeonC’s goto statement will look just like C’s, but label’s will be declared with the label keyword, not followed by a colon e.g. label foo. Labels must go by themselves on the line preceding the statement they label.

I’ll discuss more C/PygeonC syntax in my next post, What’s the matter with C?.

I have a big idea, and rather than present it with argument–a complicated task, given the myriad angles of potential attack–I’ll simply present it as future-fiction.

In the year 2007…

“The Panopticon” (casually called just “Panopticon”) is a website run by a non-profit organization, much in the spirit of Creative Commons, archive.org, the EFF, or the FSF. The organization is a mix of traditional non-profit organization and the shallow, open hierarchy typified by MediaWiki in that members of the general public are given a large stake. The project relies upon the expertise of its techies, lawyers, accountants, and tax specialists.

Panopticon is the leading website of “mass patronage” (abbreviated as ‘matronage’, by the obnoxiously clever); essentially, it is the Paypal of free culture and free software. Anyone can register an account and give money to registered creators: artists, writers, musicians, developers, etc.

Unlike Paypal, transfers on Panopticon are gifts, not quid pro quo: though users are encouraged to specify a specific work for which they are giving money, they are not buying any legal rights to these works or physical manifestations thereof. While Panopticon vets the registered creators for authenticity, not having to ensure users get what they pay for greatly simplifies Panopticon’s operations compared to Paypal’s, both legally and practically. (For some time in the beginning of the project, users could donate to just anyone whether that person or group was registered with the site, but various legal and practical issues–especially tax-related ones–led to this being discontinued.)

Because payment is all voluntary, users typically do not pay at the moment they decide to make a donation. Most user ‘transactions’ can be done with light-weight security because no funds are being guaranteed at the time: the user is simply making a note of intention in their account; at some user-specified interval, typically every few weeks, the user is sent a suggestion to review the donations they have queued up and make an actual payment.

By allowing the user to pay a periodic bill, Panopticon helps users account for their donations in their larger budget. Perhaps a user is feeling poorer this month, so they use a handy feature on the checkout page to scale down how much in total they want to give, e.g. a user might have originally made a note to give $10 dollars to Bob and $20 to Alice, but when it comes time to make an actual payment, the user might have decided they only want to spend $20, so a slider on the checkout page helps the user allot $20 in the same proportion they originally intended–1/3 to Bob and 2/3 to Alice. This is just one kind of change: all sums and donations are totally open to reconsideration, revision, or reneging until the user approves payment.

By delaying payments to a periodic interval, micropayments now make a lot more sense because many small transactions can all be payed together as one lump sum. Of course, this might end up as many tiny checks for Panopticon to send out every month, but this is mitigated by pooling of all the donations from various donators to one creator. Another mitigator is the policy that withholds payments to creators until their due payment exceeds some minimum amount.

Whereas Paypal and Amazon take a significant surcharge for each transaction, Panopticon takes a considerably smaller percentage meant to cover just some fixed costs. Most of the organization’s outlay is covered by volunteer labor and fund raisers wherein users are prodded to give a donation to the organization itself when reviewing their queued donations.

Like any good Web 2.0 service, Panopticon is something you use just as often without visiting the site as you do visiting it. Most users queue most of their donations by clicking on “donate to Panopticon” links put up by creators on their own sites. A popular Firefox plug-in let’s you view your account vitals in a handy sidebar and handle common account-management tasks (and yes, Slashdotters constantly complain about the plug-in’s inevitable memory leaks).

Some users are given the status of “expert”. Like creators, experts are vetted to ensure they are who they claim to be. The choice of term “expert” is a bit controversial as all it really means is that Panopticon has made sure the basic claims of the person’s stated bio check out; this is mainly useful to help people identify the accounts of notable persons. If a user wishes to treat a non-expert as a trusted source (something friends often do), all the same ‘expert features’ are available.

The intended role of expert varies depending upon the area of expertise, but typically they provide suggestions to users about how to donate their money. For example, a software expert might advise users how to distribute their money to a Free software project, e.g. ‘if you want to support such-and-such software project, be sure to support the creator’s of this so-and-so library which the project makes heavy use of’. A user might choose to subscribe to an expert’s feed, or might go as far as having an expert’s recommendations automatically included in their donation queues.

The choice of the name “Panopticon” was ironic. The term comes from philosopher Jeremy Bentham’s design for a mental institution in which all the inmates can be viewed in their cells from one central position. While the term connotes Orwellian oppression, the joke is that Panopticon’s users are not the ones in the cells but at the center vantage point, from which they can keep an eye on all the goings on in the madhouse that is the Internet.

While the project is mainly focused on patronage of creators of creative and technical works, it is currently exploring allowing users to make other kinds of donations, including using Panopticon as a way to give to traditional charities. By making it virtually cost-free for charities to receive donations on-line and increasing their visibility, Panopticon is fostering a healthier ‘market’ for smaller charities.

Another prospective direction is a kind of “mass commission” process: for instance, users might make agreements with a filmmaker to put up financing for a small film. The many details of this model are still sketchy.

Another hotly debated topic in the project is the question of whether to go beyond simply linking to content by actually hosting some content. On issue is that there is disagreement about whether to allow non-free licenses or not. Another issue is that, while some object on the grounds that hosting content is redundant with the work of other organizations (such as archive.org or jamendo.com), others complain that those organizations don’t fulfill their purposes well enough in the areas of ease-of-use and providing the full iTunes-like browsing experience.

In the end, Panopticon has become successful mainly for these reasons:

1. Panopticon takes a significantly smaller fee for each dollar than either Paypal or Amazon. This is due mostly to the different tax and banking standards applied to donations and non-profits than those applied to commerce; to a lesser extend it is due to the lower operating costs of a mainly volunteer organization.
2. Middle-tier bloggers in particular had nothing to lose from at least giving Panopticon a shot; such blogs have a small enough audience to not gain much from advertising, but many of them have dedicated regular readers willing to support them.
3. A big psychological obstacle to parting with money voluntarily is the nagging feeling of opportunity cost. When buying things, this aversion is usually overcome by the fact that you don’t get anything if you don’t spend anything. When donating, on the other hand, this incentive is of course absent, but still, there’s a significant difference with Panopticon: by being able to weigh potential donations against each other before actually parting with any money, the Panopticon user is at least able to manage their donation opportunity costs. Consider that, before Panopticon, if I encountered something on the Internet I had an inclination to give money to, I’d always be nagged by the feeling that my limited donation budget might be better spent on something I encounter later. Now with Panopticon, I can defer such decisions, weighing candidates for my patronage against each other before settling on a compromise that is informed by time. (Of course, there still might always be something super fantastic around the corner, but the historical record of my intentions that Panopticon presents to me helps me get past that hang-up, at least temporarily.)
4. People use Panopticon not just because they love to part with money and get nothing in return but because its social-network and recommendation-network aspects are actually uniquely useful. Much like Wikipedia is valuable because it works 90% of the time–despite the efforts of vandals, spammers, and crackpots–Panopticon too works for almost all people most of the time because of its transparency. Even if you never donate any money, Panopticon is useful as a way to track your own media consumption while maintaining privacy. Unlike other such attempts at a media-recommendation and sharing network, Panopticon, as a transparent non-profit, is trusted by its users to not abuse their privacy and precious attention by subverting them in the interests of advertisers and other “monetization” schemes. Users can set policy how their own data is made available.
5. Panopticon is an open system tolerant of competing implementations of similar ideas. For instance, users and creators can retrieve all their account data off the site in an amenable format that allows them to take it elsewhere. Some aspects of Panopticon can be freely inter-operated with in ways that allow separate sites to build new features upon Panopticon resources; this openness helps diffuse tensions over differences of opinion in the project by allowing the disaffected often to actually try out their own ideas.

UPDATE: Just in case, I grabbed the closest domain I could find: ‘panoptikon.org’. Spelt with a ‘k’ because it’s ‘kool’. Yeah, that’s the ticket. (BTW, GoDaddy has the worst payment process I’ve experienced on the web since 1996.)

My provider, SiteGround, seems to have had a bit of a catastrophe over the weekend. My databases stayed in tact just fine, but it seems my account directory got scrapped. It seems they restored from a quite old backup because the wiki remained in tact except for some modifications I made within the last couple months, and the blog was totally disfunctional. Sadly, I’ve lost my banner image (what you see is the default with this theme).

In other frustrating news, the wiki has gotten the attention of a spammer (see example), so I’ve disabled anonymous editing. Hopefully that will dissuade this spammer, but I’m sure someone will come along with a script that automatically creates accounts, so the next step will be to add captcha for registration.

I’ve come very late to using webfeeds, having only started a few months ago, but I’ve bought in to syndication to the point of removing all the sites I syndicate from my bookmarks. No more aimlessly wandering through my bookmarks to see if my regular blogs have updates.

My first foray with feeds was using the WizzReader Firefox extension, but I found that buggy with a few interface quirks. Then I used a Java app called BlogBridge for a while, which had some feed display issues and some interface clunkiness. Then I switched to another Java app, RSSOwl, which was an improvement, but it comes stock with a glut of feeds that I felt obligated to sort through rather than delete summarily; my list of feeds in RSSOwl never recovered from its initial clutter and disorganization such that I was scared to open the application.

Finally I discovered Google Reader. Here’s a few reasons why I like Reader:

1. Reader is web based, so I’m not locked to one machine.
2. Firefox 2.0′s new syndication integration feature means I can add a subscription to Reader simply by clicking on a feed link. (Not all readers support this integration yet, but I’m sure they will soon.)
3. The work I put into adding feeds and categorizing them is not trapped with Google because I can export the feeds in a standard format. Sure this is standard for client-apps, but it’s another thing for a web-based provider to not trap you to their service. (Now if only I had discovered the import feature before I did all that work to set up my feeds.)
4. While Reader initially only grabs so far back in a feed’s history when you subscribe to it, scrolling down to the bottom will automatically bring in the older content. If the other readers I tried had a similar capability to retrieve old feed items, I couldn’t find it.
5. Reader lets me tag a feed with multiple tags rather than having to organize feeds into discrete categories. Not that I ever use multiple tags, but I object to hierarchical categorization in principle.
6. I can view all of my feeds, or all my feeds with a particular tag, as one big feed with the items of the many feeds in chronological order.

Here are some mostly small things which could be improved:

1. The name is a problem, as I had vaguely heard of Google Reader, but I assumed it had something to do with e-books. What it should be called is “Google FeedReader” (see the next section).
2. The intro page makes no mention of RSS, Atom, feeds, or syndication. It just says you can “subscribe” to websites. Seems like a smart approach, but it doesn’t help users learn which sites they can subscribe to; if I weren’t in the know, I would think that I could subscribe only to sites that setup a special affiliation with Google. I guess Google’s expectation here is that users will find subscribable sites via Reader’s search feature (a bit confusingly, the search bar is labeled “add subscription” because if you put in a feed url (or a site name that returns just one result) it will ask you if you want to add that feed rather than showing a results page; perhaps this should be relabeled “Search for or add a subscription”.
3. In the expanded view of an amalgamation of multiple feeds, the “from” line doesn’t stand out, so I find it hard to identify at a glance the origin of an item when scrolling by. Perhaps the “from” line should have some kind of highlighting. Better yet, the origin of the item should go on the same line as the title, much like it appears in the list view, or perhaps it can go to the right of the title, adjusted to the right edge of the page. Either way, the visual difference would have the side benefit of reminding users that they are viewing multiple feeds as one. I see why Google hasn’t done it this way though: there’s plenty of room for it on my widescreen display, but other users may not be able to afford the screen real estate.
4. The tagging mechanism has discoverability issues, and once learned, it is clumsy for tagging many subscriptions. There should be a way to change the tags of a subscription when viewing the subscription rather than having to go to the subscription management page. My kludge around this problem is to create a tag I call “unassigned”. After adding a bunch of subscriptions, I can then go into the subscription manager, select all the unassigned with the “select unassigned” button, give them all en masse my “unassigned” tag, then filter for the unassigned tag so I can see just those subscriptions, then go through them individually to tag them all. A much simpler solution here is if Reader automatically put new subscriptions in a category called “Unassigned” or “Uncategorized”. (This would also solve the problem of untagged subscriptions in the subscription list looking too much like they’re part of the last tag group rather than on their own.)
5. It would be nice if Reader allowed me to view a feed without subscribing to it. Sure, getting rid of a feed when viewing it is a simple click away, but I hate the idea of cluttering up my subscriptions with unwanted detritus. (The better solution here is probably to allow better ways of organizing and filtering through my subscriptions, such as being able to sort them by ‘date last read’, or ‘date last updated with new content’.)
6. I’d like to bypass the screen that asks me whether I want the feed to go to my “Google Home” or to Reader. I’m sure some kind of Firefox extension could fix this, but a Reader setting would be the preferred, direct solution.
7. The left sidebar width should be adjustable, like the height of the WordPress edit windows.
8. The “feed settings…” pull down has only one button, so either add more buttons to it or just make it a button that says “unsubscribe”. Either way, move it down to be level with the line that says, “X new items [show all] All items [show only new] – Mark all as read – Refresh”. While you’re at it, put the “expanded view” and “list view” tabs down there as well. I understand making them tabs is supposed to convey general applicability (switching between views affects all subscriptions you view until you switch back to the other view), but I think conveying that idea is less important than not introducing new kinds of unnecessary widgets and splitting up the buttons that affect the currently viewed subscription. (Besides, tabs are more appropriate for simplifying navigation: they allow the user to navigate between multiple screens without getting lost. Changing display styles is not really navigation.)
9. The ‘settings’/'manage subscriptions’ screen should appear as a subscription does, with the subscription list bar on the left. A user would “return” from the settings screen simply by clicking on a feed.
10. Make the manage subscriptions button stand out more or simply put it up top next to “settings”. If this is done, the settings and manage pages should not be the same page: one for tagging and such, the other for the miscellaneous stuff.

Beyond getting readers right, syndication has some problems in general:

1. Name confusion: RSS, RSS1, RSS2, RSS1.0, RSS 2.0, Atom, XML, syndication, subscription, feed, webfeed. Which of these words should you use when explaining the concept to a non-initiate? RSS/Atom/XML are definitely out. My choice would be “feed” because it is friendly and still the most accurate. “Syndication” connotes backroom media deals for sitcom broadcast rights or printing a cartoon in newspapers. “Subscription” connotes signing up and paying money rather than something you can just “bookmark” and get for free. (It occurs to me now that perhaps the real problem is the lack of a term analogous to “bookmark”; come to think of it, we also need a term for a feed entry/item.)
2. I personally prefer feeds that display the whole content, but many feeds provide just a blurb or excerpt. Some do this to save bandwidth, others out of inattention, and still others to encourage readers to visit their sites proper. I’m sure this is hotly debated among syndication users and developers, but it seems what is needed is putting greater formatting power in the hands of feed providers so they can give their feeds a unique look and include ads. (Drawing the line at embedded scripting at this point seems reasonable to me.) On the other hand, I as a user find the sparseness of feeds one of their greatest virtues. Hopefully, this design balance will get sorted out.

With the H.264 codec, you get fantastic video compression for screen capture because it’s smart enough to recongnize an essentially unchanging screen. The image quality is near perfect with an under 1k bit rate for an umoving image.

So it’s quite annoying that both Google Video and Youtube (and in fact all the video hosting services) use a compression algorithm that is totally inappropriate for screencasting because it makes the text on the screen mostly indecipherable. Most annoying is that moving to something like H.264 would provide simulateously better quality and lower file size.

I don’t know what’s stopping them. I’ve seen plenty of high-quality flash video screencasts. Problem is, I can’t use this high-quality delivery without hosting the screencasts myself, and I’m not ready to push my $5-a-month hosting (though SiteGround claims I get 900GB a month! I haven’t asked if they really meant to capitalize that B or not; it’s possible they aren’t aware of the ‘b for bit’/'B for byte’ convention).

As it is, all my videos are uploaded to archive.org as h.264 avi files (in future, I’ll start posting them in matroska format as well, but I need to find the right tools for that conversion). This is not entirely satisfactory, as I have to direct users on where to find an h.264 codec, and they can’t get a quick preview before downloading the files. I personally find unnecessary downloading always a bit bothersome because I have to think of where to put the file; it just adds to the number of things I have to keep track of.

Speaking of Gootube, as far as I can figure, Google, whose interface I preferred using over Youtube’s clutter, could never catch up to Youtube because, as I found out myself, it takes days for Google to approve uploaded videos whereas Youtube takes less than an hour. That’s a perfectly rational reason to prefer Youtube. An alternative, more depressing explanation is that the masses are fetishists who cling sheepishly to what they already know. I hope this dynamic isn’t as strong as it seems, or else the collapse of MySpace will never come.

The oblique threats to violate network neutrality coming from the telecom industry essentially come down to one thing: no one wants to be a commodity provider because there’s never an opportunity for turning a commodity into a golden goose. With a commodity, the seller pretty much gets back just what they put into it, never much more. This explains the greater part of the enthusiasm during the tech boom: startups and investors desperately searched for a position of control, where hard work, a good idea, and being in the right place at the right time once could mean that you won’t have to do any of those things ever again to still rake in the dough. Everyone wants their piece of a positive feedback loop, and the telecoms’ desire to make the network proprietary is just exhibit 3452327325 of this.

Currently, there’s a great difficulty in convincing the general public of the danger of this. What’s needed is a good analogy (via dburrows at One for the Morning Glory):

Imagine that your power company decides that it wanted to open a line of supermarkets. At the same time, it sends out an announcement that supermarkets (due to their refrigeration requirements) are particularly heavy users of the electrical system, and as a result, the power company will add a 15% surcharge to the power bills of any building that it deems to be a supermarket. Of course, the power company’s own supermarkets are exempt from this fee. When the existing supermarkets complain, the power company says that they’re asking for special treatment and trying to get electricity “for free” and that if they don’t like its terms, they should buy their power from someone else.

This anonymous response in the post’s comments makes a strange case:

What would be more accurate to say is that the power company has to continually add more infrastructure to keep up with the increasing electricity use by everyone (likened to Bandwidth in this case). Normally the power company increases the price of electricity across the board for every customer to pay for this but noticed that some customers are utilizing most of their infrastructure. Therefore, they decided to charge the heaviest users (beneficiaries in this case) rather than charging everyone.

First, the commentor is confusing flat-fee service (what most home users get these days) with metered service: in a flat-fee service, yes, the heavy users are subsidised by the casual users, but not so in a metered service, which is the kind of service under discussion in the neutrality debate. (It occurs to me, then, that another problem in making the case to the general public is that the general public tends to only see things in terms of home-use services.)

Second, the idea that heavy users can’t be reigned in is silly. If a customer is over-taxing your metered utility, you do a few things:

1. Cap their usage.
2. Cut them off.
3. Charge a premium for going over a usage within a time period.
4. If your customer base as a whole is communally taxing the network, you can charge a premium for peak-hour usage. With a bit of programming, you can have the per-hour use fluctuate dynamically along with demand.
5. Expand your capacity so you can sell more and thereby make more money. (Despite what the commenter suggests, the consumer can’t force the provider to provide more capacity.)

In contrast, what the telecoms are threatening to do is to charge a premium for how the utility is used, not for how much of it is used. Of course, in a properly competitive market, the best solution for a provider is to use techniques 1-4 in the short term but focus on expanding capacity for the medium and long term. The telecoms don’t see their business this way. They want to do whatever it takes to capture a market and then sit back and watch their golden goose crap out the golden eggs.

Here’s Lawrence Lessig on net neutrality, yesterday.

Here’s a cute video: Net Neutrality Explained

Too much?