Archive for the 'Programming' category

 | March 28, 2011 4:57 pm

kde-iconNext Monday, I’m going to be giving a talk entitled “Writing and Publishing With Open Source Tools” at Camp KDE, the annual KDE conference for North America. For those interested in attending, the talk happens at 12:15 pm at the Hotel Kabuki, in San Francisco.

I’m really excited about the talk and I think it’s going to be excellent. (I know, having high expectations for your own performance is the route to obscurity, disappointment, and insanity.) If you live in the bay area, or are going to be near San Francisco next Monday and Tuesday, please consider coming.

Note: While I think you should come to hear me, you might also be interested in the conference as a whole. There are going to be a number of interesting talks that cover KDE developments and core technologies.

I’m particularly excited to hear about what KOffice/Calligra is up to. The abstract talks about “Office Engines” and how KOffice/Caligra can be used to build custom applications. I’m wondering if the technology might be adapted for a mobile project I’m working on. The talks on QtWebKit and the Qt Graphics tools also look neat.

One of the reasons why I’m so excited about my talk is that it brings developments with the book full circle. I first started writing “Writing With Open Source Tools” due to a request for proposals  launched by KDE nearly two years ago. Now, I’m going back to KDE to talk about the (nearly) finished project.

I’m also going talk on other developments I consider timely. For example:

  • How open source publishing tools can be used to target print, web, and eBook platforms from a single source file.
  • How editors, writers, designers, and production people can work together in a seamless, collaborative manner.
  • The strengths of an open approach and where things stand to improve. (Especially for writers and designers.)

While there will be motifs common to the Salt Lake Linux User’s group presentation, most of it is exciting and new. (Which also means untried and untested. So, if it goes well, you can expect to be enlightened. If it goes poorly, expect to be entertained. Either way, it should be a good time.) Since I haven’t quite finished the presentation, it’s also adaptable. If there is anything specific you’d like to see covered, let me know in the comments and I will try to oblige.

Show me more… »

 | December 14, 2010 2:12 am

Roman Forum

Note: Still working on the book.

For quite some time, I’ve wanted to add forums to my website.  Forums are great way to interact with your readership or to provide community support for projects.  (This is particularly important for me as I get ready to release a new version of Time Drive and an alpha of LyX-Outline.)

Every time I try to find the perfect forums software, though, I usually come away somewhat disillusioned.

This isn’t because there aren’t great platforms out there, or that they are difficult to install and administrate.  Quite the contrary, actually.  The problem is that most of the forum plugins available for WordPress (the content management system that runs my site) are ugly.

I know that design aesthetics are a personal thing.   I also know that one person’s trash is another person’s art.  But for a quasi-business website, I would like to have professional looking and attractive forums.  I want them to match the appearance of my website, I would like the headers and backgrounds to use my stylesheet, and it would be nice if the visual hierarchy were established via typography.

Are these such unrealistic desires?

Every time I look, though, I fail to find a forum plugin that meets my needs and satisfies my tastes.  There are some that come close, but as math instructors have told me since grade school, “Close is still wrong.”  Life usually doesn’t offer partial credit.

This last round, I got so frustrated that I decided to create a somewhat custom solution. (Action born of frustration is becoming a theme in my work.)  Truly, if you want something that matches your vision, you really need to do it yourself.  And I have.  After a month of work, you can find my now-functioning forums at www.oak-tree.us/mingle-forum.

For those too lazy to click on the link, here’s a preview.

Oak-Tree.us Forums

Oak-Tree.us Forums - Grid

While there are several goodies lurking below the surface, here are the most important features:

  • The forum is a stand-alone plugin for WordPress.
  • The user database is integrated with the website database.  (This means that when people are registered for the website, they are also registered for the forums.)
  • There is a notification system.  Users receive an email (or RSS item) when a response to one of their threads is posted.
  • The administration panel integrates with the WordPress dashboard.
  • The stylesheet uses the website headings and typographical hierarchy.
  • The plugin allows skins.

Most of these features come from forking Mingle forums, a WordPress plugin.  But there are also some significant changes to the way in which the forum integrates with the website and a completely rewritten/designed the header and footer.  (In the case of the footer, I simply got rid of it.)

In the near future, I’m going to make a few additional changes.  I’d like for the plugin to use a WordPress template instead of hard coding the layout.  I’d also like to add a preferences pane.  In the meantime, though, I thought I would post the files in the hope that they are useful.  Enjoy!

The project is licensed under the GPL.

Downloads

Somewhat Simple Forums (version 0.1).  WordPress plugin forked from Mingle forums.  In includes several typographical enhancements.

Installation

To install:

  1. Download the archive file.
  2. Go to Plugins > New > Upload.  From there, find the .zip file on your hard drive and upload to your server.
  3. Activate the plugin.

After the plugin has been activated:

  1. Create a new page for your forum.
  2. Turn the comments off.
  3. Paste the command [mingleforum] onto the page.
  4. Add categories and forums to the database.

 | October 26, 2010 5:05 pm

Note: Still working on the book, but because I needed a couple hour break, I decided to tackle some LyX-Outline stuff.  This post is related to one item on the to-do list.

Because I need to get away from the book for a while, I decided I would take a break and work on LyX-Outline stuff.  This includes one of the long-standing to-do items: adding support for sections of arbitrary length. Before I get too far down an implementation, though, I would like to request feedback from potential users.

I’ve been trying to find a good way to do this for several months and I think that I’ve finally determined how I would like for it to work.  (At least in the first release.)  Here’s what I propose:

  • Rather than hard-code a special inset into the C++, I think that I am going to add a style for these sections.
  • It will work as a module that you can add to any document you happen to be working on.  Special LyX-Outline templates will include the module by default.
  • The style will rank below all other headings in the document: section, subsection, subsubsection, paragraph, subparagraph.  This would allow for you to organize chunks of text in the body.  (I agree, it would be better to allow you to specify which level you would like this container to exist on, but LyX requires you to specify the indentation level of a particular heading.)
  • For higher level structures (e.g., section, subsection, subsubsection, paragraph, subparagraph), I would anticipate that you would use the other logical headings already provided by the document class.  For creative writing, I am creating layouts which include a heading for scene, that would work in a similar way to this “section of arbitrary length” but provide a container, so you can still group these arbitrary sections into folders.
  • Text in the title will not be added when you export/compile your document.
  • Like other types of section headings, you can add notes to them (which then appear in the corkboard and outline pane).
  • You can convert the “section of arbitrary length” title to a standard LyX/LaTeX section heading.

Does this proposal meet your needs?  This model would give you up to eight levels of hierarchy if working with one of the standard classes and up to four if working on a creative project.  Is that good enough?

After some investigation, I’ve found that completely adopting Scrivener’s model of an infinite number of folders/files would be extremely, prohibitively difficult in LyX.  Yes, it could be done, but it would require some significant rewrites to the way that LyX works.  My goal is to release LyX-Outline as soon as possible (literally, the day after the book has been finished) and I don’t want to get back into the business of major plumbing.  But if it is needed, I will.

There is also a second question.  What should these “sections of arbitrary length” be called?

Scrivener refers to blocks of text as “Chunks.”  That term in LyX, however, refers to something else.  (A block of code when using Sweave.)  LyX also reserves several other heading labels for use, meaning that “part”, “section”, “subsection”, “subsubsection”, “paragraph” and “subparagraph” are also out.

Anyone have any ideas?  I’m terrible when it comes to naming things, and if I make something up, it come out with a label like “Oak-Tree Anthropomorphic Writing Sections of Arbitrary Length”. That would just be bad, and humiliating.

Other people have recommended “Scrivening” and “Text-Block” as potential contenders, which I both like.  But I thought I would open the floor to other nominations before trying to make a decision.

 | October 4, 2010 4:09 pm

complexity1Note: The regular programming of this website has been interrupted due to a need to finish the Open Source Writing book.  It will resume once I have sent a draft off to my editor/publisher.  They have been very patient and I have been irresponsible. Though a month of hard work has left me in better shape than I thought I would be in at this time.

While I am supposed to be working on the Open Source Writing book, I read a very interesting piece on ZdNet this morning that I wanted to respond.  Entitled, “The new reality: Technology must be self-evident,” the piece caused two simultaneous reactions.

First, I agreed with the spirit of the message.  For new technology products to be successful, they must be “self-evident”, which means they must be intuitive.  You must be able to understand their fundamentals by sitting down and starting to explore.

But even though I understand and appreciate the big message, I couldn’t disagree more with the way that Jason Hiner (the piece’s author) says we need to get there:

The new way of building tech products is about less rather than more. It’s about removing (or never implementing) rarely-used features rather than piling on as many as you can cram into a product. It’s about not being hyper-reactive to a handful of user requests that may not reflect the larger user base. Most of all, it’s about discipline — the discipline to stick to a product’s core functionality and avoid the temptation of product creep.

The end game of this disciplined approach is building products that have a user experience (UX) that is almost completely self-evident. That’s why products with stripped-down GUIs and feature sets like the iPad, Android, Gmail, and Salesforce.com have become meteoric success stories.

and then he offers a few concrete examples of “poorly designed products”:

Let’s pick on Microsoft Word as an example of the old way. Although it is far from alone in this phenomenon, it is one of the most popular software applications of all time. The product started out great. It was one of the first word processors to offer WYSIWYG and introduce a toolbar. It quickly conquered text-based Word Perfect by the mid-1990s.

But, then lots of different Windows and Mac users told Microsoft all of the things they wished the product could do or ways that they wished it would work and Microsoft took the best suggestions and kept adding on .more and more features and options to the point that today’s Word is so bloated, over-complicated, and bogged down with options that it’s often difficult to figure out how to do basic tasks. In fact, it often requires a bunch of documentation and training to figure out how to use it.

Simplicity is the Realm of the Stupid

I’m sorry, but this where I have to start “kicking against the pricks”.  Less is not more.  Usually, it’s just less.

It may be tempting to say that hammers/nails and screwdrivers/screws accomplish the same purpose (fastening materials together), and for that reason we should eliminate one of the options.  We may say to ourselves “Let’s get rid of screwdrivers/screws, since they are more complicated.  It will result in a cleaner and more productive workspace.”

But before doing that, let’s step back and ask an important question: What purpose does this action serve?

Yes, we free up space in the workshop and reduce confusion.  It’s no longer necessary to teach people how to twist screws.  A cleaner workspace is a bonus.  But we take the action at the expense of a well-designed and elegant option.  Because of their larger surface area and manner of installation, screws can be used in instances  where nails are less useful.  They result in a better join.  Thus, trying to get rid of a well-designed option in the name of “simplicity” or “choice abundance” is actually harmful.  It results in the proliferation of an inferior option because the superior choice is “more complex” or might require that we seek out a bit of training and learn when to use one tool over the other..

But the insanity doesn’t stop there.  In an attempt to simplify, a product designer invariably indulges in the stupidity of Average Joe User.  She attempts to craft a generic human being that is meant to stand in for you, your mom and anyone else who will make use of the product.  She then meets Average Joe’s needs, or what she thinks are average Joe’s needs.

But of course, there’s just one problem.  There is no such thing as Average Joe User.  He. Does. Not. Exist.  I don’t use a computer in the same way as my mom.  Or my grandparents.  There is no average of our activities that will somehow make all of us happy.  This is why people submit feature requests and lobby for new options.

Yet, Microsoft Word does an admirable job of meeting our respective needs because people like me, my mom and my grandfather have requested certain capabilities.  My mom (who is a school teacher) can sit down and write a lesson plan, my grandfather (who is a businessman) can write a letter, and I can use it to write a scientific report.  If some product manager tried to start removing arbitrary features that my mom (who probably best reflects Average Joe) doesn’t need, it would negatively affect both my grandfather and I.

Rather than improve the quality of the product, it would castrate it into uselessness.  All in the name of simplicity and “confusion avoidance.”

Aim for Elegance

Which really brings me to my main point.  In software engineering, what we are aiming for isn’t simplicity.  Rather, it’s the intersection of good engineering and smart design, which I’ll refer to as “elegance.”  Edward Tufte has a quote that sums it up my feelings nicely [paraphrased]:

Confusion isn’t the result of complexity, but of poor design.

An elegant product is self-evident and clear, but still retains its power and functionality.  And it’s infinitely preferable to a “simple product.”  As an example, let’s return to analyzing Microsoft Word.

If Word is so confusing or undesirable, I’d really like to know, where is the Word processor or document writing system that challenges its hegemony? Who is advocating that we drop Word in favor of other tools? Where is the simple piece of software software that accomplishes everything we “need” and nothing we don’t?

Can it be found in Google Docs or OpenOffice (which is just as complicated as Word, if not more so)?  What about an alternative system like LaTeX or a LaTeX front-end like LyX (my own personal choice)?

While the alternatives are compelling and work tremendously well, they haven’t stolen any significant market share from Word. Microsoft Word enjoys dominance because it is a capable Word processor for most people. Full stop. All of the other products taken together probably don’t even amount to more than 5% of Word’s user base.  This is because Word is an elegant tool.  It’s not often the best tool for the job, but it is usually adequate and often good.  Nor would I call it “complex” or alienating.  As I said earlier, it works for the majority of people most of the time.

Or perhaps someone could show me the army of ignorance that struggles to do simple things in Word?

Yes, people often struggle to do hard things (mail merge, query databases, build interactive forms, etc). But they this is true of hard things in other programs as well and in simple programs, the options aren’t available.  Which is like comparing a duck to a cow.

From within Word to do simple things is straightforward. You open the program and start typing. You click on the bold button, or on an appropriate style.  It’s all self-evident and available. The UI is clear.  There is no significant learning curve. I’m not sure that there is a learning curve at all for basic tasks.  You simply start writing and place one word after another.  Billions of people are able to do this without any significant difficulty, including people with physical disabilities. While I might like to knock it, Microsoft Word is a piece of Very Good Software.

So what does stripping features accomplish?  It doesn’t make the use of basic features more obvious.  Nor does it enable the use of advanced options (since they are simply removed).  For that matter, it might not even influence the speed of the program (the so-called bloat), since that is more of a question of program optimization than number of raw features.

In the case of Word, simplicity isn’t a virtue.  But elegance is.  Instead of removing the features, the goal should be to integrate them into the program in a better manner and to make their function more obvious.  It is, in effect, a design challenge.  Word 2010 is a better program than Word 2003 because it allows you to both do more and makes the tools more available.

Sometimes Complexity Is Important

Which raises another relevant point.  Sometimes a tool needs to be sophisticated and specialized.  For example, where is the serious contender to Photoshop?

Maybe someone can point me at a few consumer level photo tools that are meeting the needs of mom and dad, but there is no “simple” piece of software that is threatening Adobe’s flagship product.  Nor do the alternatives address a wider variety of needs.  Photoshop is used by graphic designers, illustrators, artists, scientists and engineers.  Yes, it’s complicated and requires instruction, but after you’ve mounted the learning curve, the UI and palette design is also highly logical, consistent and useful.  In this case, sophisticated is better than simple.

And it’s obvious.  If you look at the world of digital art, Photoshop (and other specialized tools) are the choice for content creation.  Certainly, some stuff has come off of “simple” tools, like the iPad, but these these are akin to a symphony played on a collection of iPhones. They are novelties, and interesting for that reason. iPad is simply not the equal of a computer + Photoshop + Wacom.  I would even go so far as to say that the “simplicity” is a handicap, as It is much harder to create something of quality.

(Please no videos of sketch artists using iPad.  I’ve seen them, they’re utterly inferior.  Wacom can interpret pitch, pressure and different types of point.  It comes very close to the subtlety of real artistic tools.  It’s like comparing 5 year old soccer to the world cup.  There is no comparison and anyone who seriously advocates such an option is simply not worth my time.  Go spend some time around working artists, or better yet, take a few classes and try and use an iPad.  Then we can talk.)

iPad is an interesting machine, and Salesforce.com is tremendously cool. But they both serve niche markets and since they are so targeted, they don’t really fall into the inanities of “Average Joe.” In fact, I would even go so far as to say that their success has little to do with “simplicity” and much more to do with elegance.  They meet specific needs very well.

The iPad is a companion device optimized for consumption: reading, email, websurfing.  These are major activities for many users, and for that reason, it’s enjoyed success.  Salesforce.com also nicely meets a very specific targeted need.  It helps find contacts and push products/services.  Again, a very narrow niche that is targeted well.  But even there, it has hardly replaced Outlook. It’s much more a complement than a “simple replacement.” A case of “More is more.”

Conclusion

So while I agree with the Hiner’s tagline, “Technology must be self-evident”, I disagree with the prescription on how to get there. Rather than aim for simplicity, tech needs to aim for elegance. In the physical sciences, we use Maxwell’s equations because they elegantly summarize many phenomenon, not because they are simple.

Ditto for good software. If the features are present and elegantly incorporated into the UI, they will be discoverable and that brings value to a product.  Which is why people stay with Word and MS Office. Yes, they could switch to “simpler” alternatives, but in many cases those options are the bad “simple”. They’re crippled, which makes them worthless.

Give me elegance any day.  An elegant product meets the needs of its users.  It incorporates features, good engineering and smart design.  It makes hard things easy and enables the impossible.  It is, simply, superior in every way.

 | September 2, 2010 5:34 pm

Fire DanceI’ve always been amazed that In the wilds of the Internet, fires can be ignited, extinguished and forgotten at terrifying speed.  Certainly, we say that the Internet has a long memory; we even occasionally visit Google to demonstrate it.  (Usually by uncovering the evidence of past drunken exploits.)

And such sayings may be true.  But they’re true in the way that libraries archive knowledge or that history never forgets.  The information is accessible and available, but to find it requires work.  (Sometimes a lot of work.)

The meme does not apply to the living memory of the Internet, that body of knowledge that the denizens (and it’s most important search engines) have within easy recall.  The living memory, like the Internet’s attention span, is extremely short.  Non-existent, even.

This means that if you wish to contribute to a particular discussion or flame-fest, you had better do so quickly and concisely.  Otherwise, the opportunity may pass you by forever.

In many respects, this is a good thing.  It’s an important reminder that most of our concerns are temporary and that most debates have about as much importance as that of metaphorical angels dancing on the heads of imagined pins.

In other ways, though, it is a true shame.  If you’re trying to respond quickly, it’s not always possible to say something insightful or profound.  You may not even address the points of the original article because you are too busy formulating a comeback.

(Maybe this is why virtual fisticuffs so often resemble the dynamics of sibling squabbles?)

One such article appeared on the Interwebs nearly a month ago, written by the emerging polemicist Benjamin Humphrey.  Entitled “Dude, you’re a 35 year old with a neck beard”, the thing set off what can only be described as a forest fire.  It brought up Linux ideology, geek stereotypes and religion within the same posting.  It even had the audacity to suggest that, at least as far as technology goes, ideology should serve progress and not the other way round.  (Very brave positions, all.)

Predictably, people jumped all over it.  There were hundreds of angry comments, email flame wars and even a few scattered blog responses.

Note: I sincerely hope that Humphrey doesn’t become too gun shy with his writing.  He’s a fantastic contrarian and has a knack for making me think.  This article will be the third response I’ve written to his work, and that says something.  The world needs more provocative opinions and controversial ideas.  And even though discussions of such material may occasionally – or even frequently – explode doesn’t mean that they should be avoided.  Humphrey is very good at bringing these such topics to the attention of the open source community.  It would be a pity if he stopped simply because he’s occasionally gotten himself burned (even if they were third degree and required skin grafts).

I think Humphrey’s article prompted such an explosion because the points he proffers are interesting, important and timely.  They highlight changes that are happening in the open source community and demonstrate that, though Open Source may have started as an ideological movement (complete with its own priesthood), it’s not going to stay that way forever.  Humphrey also offered the opinion that this is a good thing, and that the purity police (in his language, the “beardies”) needn’t destroy their own legacy to prevent it from changing.

I largely agree with this message, but being the longwinded and engaged sort of fellow I am, I had a few points that I wanted to add.  More logs on the fire, if you will.

However, real life and other responsibilities got in the way.  I wasn’t able to sit, formulate my thoughts and respond in a timely manner.  For that reason, I’ve arrived late to the conflict.  And though I bring material, explosives and (most importantly) fuel, I’ve found an otherwise spectacular disaster reduced to barely smoking embers.

But since I’ve written the damn thing and I’m infatuated with the sound of my own voice, I’m going to breathe some life back into this flame.  Over the next few days, I’d like to take Humphrey’s argument and extend it to a logical conclusion.  Specifically, there are three points I’d like to explore:

  1. Humphrey is correct, the open source worlds are changing and Purity of Thought is taking a back seat to innovation and progress.  This is a scary, although not a bad, thing.
  2. The shifts are happening because the open source tent is expanding.  This is a necessary step to eventual world domination, or as Mark Shuttleworth, to “crossing of the chasm.”
  3. Ultimately, these changes will be a Good Thing.  Even though new people are entering the community and they’re kind of strange, that does not mean that there should be battles to the death.  Both the interests of the beardies and those of the new denizens can align and influence one another.  Open Source if a process, not a product, and works best by combining the interests of many.

The Italians have saying:

Since the house is on fire, let us warm ourselves.

Thanks to Humphrey, the house has already burned down (in addition to sizable parts of the garden and grounds).   But that does not mean I can’t make use of his magnificent ruin, or its smoldering remains.  I intend not only to warm myself, but to dance amidst its flames.  I sincerely hope that you’ll join in and help raise a mere blaze to a proper firestorm.

 | August 17, 2010 7:07 pm

Though I love Ubuntu, there is one aspect of its package management that I am significantly less than thrilled with, the pace of incremental updates.

Prior to release, Ubuntu (and other software manufacturers) spend a great deal of time testing, tweaking and otherwise ensuring that the software they ship is of high quality.  This is a good thing, it ensures that the platform is stable and works well.

However, there is also a downside.  It means that, other than very minor security upgrades, software only gets updated during Ubuntu’s six month refresh cycle,  and, if you don’t upgrade to the newest Ubuntu, you will often get stuck using older versions.  (Even if those older versions have known bugs and issues.)

Most of the time, this isn’t a tremendously big deal.  After all, Ubuntu is completely free and upgrades are mostly painless.  Sometimes it is, though, and there is one case is currently having a negative impact on Ubuntu (10.04) users who use LyX.

Show me more… »

 | August 5, 2010 5:33 pm

At the annual GUADEC conference, the meeting of the Gnome developers, some rather interesting statistics were released.  These statistics were meant to answer some important questions and provide insight into how the community worked, namely:

  • How big is Gnome?
  • How many paid developers are there?
  • Who writes all of this software and why?

But I’m not sure they had that particular effect.

As part of that report,  a discrepancy in the number of contributions made by Red Hat – the packagers of the largest Linux server distribution – and Canonical – the packagers of the largest Linux desktop distribution — was discovered.  And it isn’t a small discrepancy, either:

  • During the past few years, Red Hat made 70,790 commits to the Gnome project.  This accounted for 16.3% of all contributions.
  • In the same time period, Canonical made 4487 commits, accounting for 1.03% of all contributions.
  • This means that, despite its position as the number one desktop distribution, contributions from Red Hat outnumber those from Canonical by more than 16 times.

This is an explosive finding and has lead to some miscellaneous ugliness.

According to Red Hat, Ubuntu is riding its coattails.  They’re taking advantage of the work of other companies.  According to Ubuntu, Red Hat is engaged in tribalism that puts it in the company of racists, misogynists and others.  (Yes, I’m oversimplifying and removing the niceties of urbane disagreement.)

This happens from time to time.  Open source is filled with passionate people who wish to change the world through technology.  They feel strongly about their work and when disagreements invariably arise, they quite often erupt into bouts of temporary ugliness.  But even though such explosions flare frequency (and are just as quickly forgotten), trying to understand what causes them is important; and that’s particularly true in this case.

Show me more… »

 | August 2, 2010 2:31 pm

Presidential-SealFrom a structural standpoint, memos are interesting documents.  They share some attributes in common with a letter, and others in common with a structured report.  Because of this, LaTeX uses have historically used a document class meant for one of those documents when composing memos.  There isn’t anything wrong with that.  It’s very easy to begin a new “article” and then add the needed “To”, “From”, “Subject” and “Date” lines manually.

However, while this is easy, it still requires that you do a bit of “finger painting”.  As a (more or less) dedicated user of LaTeX, I dislike finger painting.  Quite a bit, actually.  It might even be accurate to say that I am philosophically opposed to finger painting.

The major advantage of using LaTeX is that, like XHTML and CSS, it can separate your content from the markup and formatting that determines its appearance.  When you fingerpaint, however, you mix them all together.  Your appearance syntax and the content of your document get inseparably intertwined.  In some cases, you couldn’t separate them even if you wanted to.  For that reason, finger painting is just wrong.  But even though finger paining in LaTeX may feel wrong, I’ve never had a reason to create a better solution.

That is, until a few a weeks ago.

Quite recently, I’ve become involved in a new project and because of what the project is and the need to official keep records of communication, I’ve found myself writing memos.  Lot’s of memos.  More memos than I’ve ever written at any other point in my life.  Moreover, I’m going to be writing (many) memos for the foreseeable future.  On Friday, after finishing (yet another) memo, I decided that it was time to create a more formal memo template/document class for LaTeX.

I’m calling it texMemo.

Show me more… »

 | July 20, 2010 4:45 pm

imageOpen Source is unique in that much of it arises from a desire to scratch one’s own itches.  Or at least the very best Open Source does.  It’s written by the very people who will use it, and as a result, meets a real rather than perceived need.  This lets it bypass any inane stupidity associated with Average Joe User.

Unfortunately, there is also a downside.  A great deal of open source software is only developed to the point of being “Good Enough.”  The program’s authors know exactly what they need to accomplish and do not extend the capabilities of the code much beyond their own front doors, which is a true shame.

I certainly understand their rationale.  “Going the last mile” to a fully polished utility is a hell of a lot of work.  In fact, the last mile may account for up to 60% of the man-hours (based on an unscientific survey of my work on LyX-Outline and Time Drive).  It involves tracking down bugs, optimizing/refactoring code, and extensive testing.  Underestimating challenges associated with the “last mile” have lead to delays in my projects, and I’ve heard the same thing from other developers.

What this often means is that the testing, polishing, and the other fine-tuning needed for superb software doesn’t happen.  Even worse, many of the minor annoyances and inconsistencies never get addressed and are subsequently passed downstream to other projects and users.

Of course, what is a minor annoyance to upstream becomes a major headache to those downstream.  After all, such projects (like Linux distributions) not only have to deal with the “minor” problems of one upstream source, but of thousands.  Moreover, the annoyances build upon one another until they become paralyzing and impede forward progress.

The Ubuntu project has a term for these annoyances/inconsistencies that I quite like.  It refers to them as “paper cuts”.  In the real world, a paper cut is a trivial wound that hurts far more than it should.  Ditto for the software equivalent.  In the big picture, the problem shouldn’t be a big deal; but it is, and whenever you run into it, it stings.

Here’s Ubuntu’s formal definition:

A paper cut is a trivially fixable bug.  They may be an unintended problem occurring within an existing piece of software, the presence of which makes a computer more difficult or less pleasant to use, that is easy to fix [and really shouldn’t be there].

As you can probably tell, I think that resolving these annoyances is important.

To users, Paper Cuts influence their perception of the platform, and may be responsible for driving people away from Linux; and overcoming a first impression is ludicrously difficult.  If someone has had a poor experience with Linux (or Open Source) in the past, it is not only likely to influence their own future choices, but also what recommendations they make to friends and colleagues.  Put another way, the effect of poor impressions (such as those created by paper cuts) isn’t linear, it’s exponential, and far out of proportion to their overall severity.  For this reason, the resolution of paper cuts might be the most important contribution that Ubuntu has made to the world of Open Source.

Now, before someone takes me task, let me explain.  I’m not talking about the actual bug fixes themselves – even together, the fixes are trivial.  I’m talking about the culture that has begun to permeate the Ubuntu project.  You’ve probably run into evidence of it.  It’s the culture that prompted to Mark Shuttleworth to get on stage at OSCON 2008 and encourage developers to out-prettify Apple within two years; the culture that values a highly polished product and says that we should refine existing functionality before piling on new features; and the culture that has caused Linux to hit its stride as an operating system.

And it’s a spectacularly Good Thing.  Due to the culture shifts that Ubuntu (and related projects) have caused, there is finally some impetus for up-stream developers (like me) to polish our releases and create superb software.  With impetus comes incentive, and incentive has the ability to actually change behavior.

(Which reminds me, I should probably get back to work on LyX-Outline.)

 | July 19, 2010 9:00 pm

In the past few days, I’ve received several emails asking when LyX-Outline will be available.  (I had originally hoped to release an alpha/beta preview by July 15, which has not happened.)

This is a fair question.  I know that (yet) another self-imposed deadline has come and gone.  I know that this destroys confidence in the project as a whole and casts doubt on my ability to deliver.  I’m aware that it causes a “credibility crisis” and that it makes LyX-Outline look like “vaporware”, as one potential user was so … kind … as to point out.  But even knowing all of that, I’m afraid that I can’t give a firm answer to the question of, “When will you finally publish a binary?”  The simple truth is that I’m not sure when I’ll be able to finish.

Back in June, I was sure that I would have everything wrapped up by mid-July, then I discovered a raft of things that needed to be fixed.  Many of these tasks still aren’t done, so I’m revising my target date, again.  Instead of late July, my current guess is  early August.

But it really isn’t possible for me to commit to a firm date.  I have other responsibilities that need to take higher priority.  As a result, the official answer to the question of “When can I download LyX-Outline?” is this:

LyX-Outline will be available when it’s ready.

First impressions are forever, unfortunately; and I want both the alpha and beta releases to have a degree of polish.

If you are excitedly waiting for the release, however, I understand that this may not be what you would like to hear.  Solid, reliable dates are much better than tenuous goals and vapor.  For that reason, I’ve decided to publish my task list for the alpha milestone.  This will let you see what features I’m currently planning, provide an idea about how development is progressing and allow for you to provide input.  I will update the list as features are completed.

As always, I would be very interested in user feedback.  If you have any ideas for things you would like to see, please let me know in the comments or go to the project homepage and file a blueprint.  I would like to make LyX-Outline useful to as many people as possible.  For that to happen, though, I need your input.

Note: If you are a developer and see an unfinished item that sparks your interest, let me know.  Code contributions from anyone are welcome.  For instructions on how to check out/compile the current trunk version, see this post.

Show me more… »