Sprouted ~ Software that grows with you...

Every once in a while I get a request for a printable version of the Journler manual. The help files are extensive, and having them in print would make reading them more enjoyable for many people.

A PDF version of the help files actually exists, but it’s hidden. I just wanted to mention it again so that everyone knows about it. The PDF version covers Journler 2.5.3 and, while still very relevant, will be somewhat dated when the 2.5.4 change are taken into account. I will be updating the PDF manual once I release 2.5.4.

Download the Journler Manual (PDF - 2.9MB)

“Journler is provided free of charge and always will be. No matter how often Journler is updated or what additions are made, you will have free access to all of its features for an unlimited time.” — Philip Dow, August 2006

When Journler 2.5 was released I introduced a distinction that I hoped would allow me to remain as close as possible to this promise. I wrote at the time that, as an indie developer I was doing my best to stay true to my original intentions but it was becoming more and more difficult.

It has continued this way. Generally speaking, downloads do not lead to donations, and when they do it is often the minimum. In the past few months, Journler has become more and more popular but I have earned less and less money. I have come to accept the inevitable fact that an approach to software development which sustains itself primarily by gift is difficult if not impossible to maintain.

The problems are frustrating and circular. As Journler became more popular, the support requirements became greater. I ended up spending more time supporting users than releasing updates. With fewer updates, less income came in. The result is that, paradoxically, Journler’s recent popularity has led to fewer earnings.

It has been suggested that I solve my problems by hiring additional help. But in order to hire help I need Journler to produce more income. In order to increase my income I must release updates. In order to release those updates I need to hire help, which of course costs money. Quite the bind.

I remain committed to producing a great product with steady updates supported by timely customer service. Thousands of users from across the world have found in Journler a useful and dependable application. I aim to keep it that way. Not to mention the great improvements that I’m just itching to work on if I can only find the time. I want to see Journler grow just as much as you do.

To make sure this happens I have settled on the difficult decision of transforming Journler into a shareware application. Beginning with 2.6, the unenforced distinction between personal and non-personal licenses will be eliminated. Instead, a single license will cost $34.95 with an evaluation period of 60 days. Student and bulk discounts will be offered.

If you have already purchased a license or donated, the cost of the 2.6 upgrade will vary depending upon the circumstances of your contribution. For anyone with a non-personal license, the 2.6 upgrade will be free. Users who donated for a personal use license will be required to make up the difference between their contribution and the current price of $24.95. For example, if you donated $10 then the 2.6 upgrade will cost $14.95.

On Wednesday, January 23rd I will effect the price change while leaving the fee noncompulsory until 2.6 is actually released. That is, beginning Wednesday I will still be requesting donations for personal use and requiring licenses for non-personal use, but at the single price of $34.95. As in the past, you may choose whether you will abide by those terms. However, once 2.6 is released there will be an evaluation period of 60 days at which time the purchase of a license will be required.

You may purchase a license at any point between now and Wednesday. Doing so ensures a savings of $10 on the price of v2.6, whether you make a partial or full purchase. Individuals who purchase a license for $34.95 after January 23rd will not be required to pay any upgrade fee for v2.6.

This has been a difficult decision, but it is the right one. Software has become my business, and the only way I am able to continue offering quality products with regular updates and timely customer service is if I treat these products as any business does. Thanks for your support and understanding.

After a bit of a lull I’m back in the full swing of things. I was home over the holidays and took a break from the coding to focus on my overflowing support inboxes. I answered and filed hundreds of emails, some as old as a year! It is a huge relief to finally have most of the support emails answered. One of my news year’s resolutions is to go over the inboxes every two weeks to prevent them from becoming unmanageable. There are still emails to answer, so if you haven’t heard from me yet wait a few days and then write back if there’s still no reply.

Journler 2.5.4 is just around the corner. The 2.5.4 update ensures Leopard compatibility, fixes a number of problems and greatly improves tagging. The beta 14 version has been afloat for over a month and I’m pleased with the results. A beta 15 was released yesterday. There are just a couple more issues to address and then 2.5.4 will be ready for the public. If you can’t wait any longer you can give the beta a go, or if you’re running Mac OS 10.5 Leopard you should already be using it. Download Journler 2.5.4 b15 and read this post.
I’ll be roaming the Macworld trade floor this afternoon and tomorrow. If you’re in town for the conference and would like to meet up or even see some of the beautiful North Beach neighborhood where I live, send me an email.

In my last blog post from mid October I mentioned that the Journler license would be changing. I have made a final decision in this regards and will discuss the changes in my next post.

Journler 2.5.4 For Leopard
It’s a big day for Mac users. Mac OS X Leopard is available, and I’m certain many of you are already installing it. There are a lot of great changes to the OS, and developers have been busy preparing their applications.

Journler 2.5.4 beta is the pre-release version of Journler’s next incremental update. Journler 2.5.4 includes a number of changes, but most important for early Leopard adopters, it ensures compatibility with the new OS.

Although 2.5.4 is still in the beta stage, it is strongly advised that Leopard users update their copies of Journler. The current version of Journler sports a number of compatibility issues which 2.5.4 addresses. Of course, Mac OS Tigers users may update to the beta as well, but it is not necessary.

Download Journler 2.5.4 beta

Please note that it may be necessary to reset your password with this update. You’ll find the instructions at the Journler wiki: Resetting your Password. All beta users should enable auto-updating in Journler’s preferences and monitor the beta forum for announcements.

Journler Drops Support For Blogging
I have decided to drop blogging from Journler. I originally added blogging because it was a popular request, but I have never been able to fully realize the feature. Rather than continue to support a half-finished product which I feel reflects poorly on the overall quality of Journler, I chose to remove it. If you are a prolific or even causal blogger you will need to use another program such as MarsEdit or Ecto for that portion of your journaling.

Journler 2.5.4 is the Last Donationware Version of Journler
I intend to release the final version of Journler 2.5.4 by November 15th. This will be the last version of Journler to use donations or the dual license system. Slated for release in two to three months, Journler 2.6 will include a number of major improvements and fully take advantage of the new Leopard features. It will require a full license for all uses.

I have not come to this decision lightly. While there are many reasons why I have chosen to stop offering Journler as donationware, two stand out. First, Journler has grown too big. I am no longer capable of single handedly managing a project of this size. I require assistance and additional expertise, and both come at a price.

Second, I have come to the conclusion that the donationware model is not sustainable. Software development is what I do for a living, and while I have had some financial success, this is the second month I will not break even since Journler 2.5 was released. Software development is a cyclical business, I understand that, but I must be able to pay the bills consistently. And if I’m going to take on additional help, I’ll certainly need a steady income.

The pricing structure for Journler 2.6 will be announced at a later date. In the meantime, enjoy the 2.5.4 beta if you’re on Leopard, and keep an eye out for the final version in mid November if you’re not.

Edit: Yay! It’s the 16th and the downloads are working again.

Download Journler 2.5.3 here

I have reached the bi-weekly bandwidth limit on my .Mac account and the spigot has been turned off. External access to the account has been suspended until the 16th. Because I host the Journler download on my .Mac account, direct links to the Journler download from any number of sites are not working. Up until about five minutes ago the auto-update feature was also not working.

It blows my mind that I can move 125GB of a 9.8MB download in two weeks, but it is the case. I guess that’s a good thing! A maxed out .Mac account offers 250GB of monthly bandwidth, roughly 26,000 Journler downloads, but it is split into two periods for the month. The one begins on the 1st and the other on the 16th. If you surpass half the total during the first period, as I have, the download stream is disabled until the start of the second. This isn’t terrible. My account is still active, I just have to wait until the 16th for downloads to resume.

Until then I have implemented a temporary workaround. I am now hosting the Journler download from journler.com itself. If you tried to auto-updated earlier today and it did not work, give it another go. If you are looking to download Journler directly, you may use this direct download link instead. Sites which insist on having a hard link to a fixed location, such as VersionTracker and MacUpdate, will not work with the Journler download until the 16th.

Journler 2.5.3 is out and ready for download! Use Journler’s auto-update feature (Journler menu > Check for Updates) or Download Journler 2.5.3 now. For complete instructions on updating Journler, see below.

v2.5.3 is a maintenance release for the 2.5 series and is a recommend update for all Journler users. v2.5.3 features numerous improvements and a lot of behind the scenes work, including:

1. German localization - many thanks to Andreas Häne
2. Danish localization - many thanks to Preben Nielson
3. Crash fix related to Safari 3 beta
4. Fixed memory leak related to live word count
5. Punctuation now allowed in smart folders, no apostrophes or quotes though
6. Improved resource management
7. Attachment drags from Mail now work
8. Updated help files
9. Many, many more improvements and additions

If you are updating Journler using the direct link provided above, follow these steps to install the new version:

1. Quit Journler
2. Download the disk image. It will mount on your desktop
3. Drag the version of Journler on the disk image to your Applications folder or wherever you keep your Journler application. It is ok to replace the old version of Journler. Your journal data is stored elsewhere and will not be effected
4. Once you have copied Journler to your Applications folder, you may close the disk image and trash it
5. Run Journler 2.5.3. Journler may ask for access to your Keychain. This is normal and you should allow it

Be sure to check out the Journler Forums if you have any questions or run into any problems with the update. Enjoy!

Adam Bell recently posted a piece on scripting Journler for MacScripter.net, which is this week’s cover article. Adam takes an in-depth look at Journler’s scriptability and offers solutions for advanced tasks such as backing up your journal, integrating Journler and Quicksilver and scripting Journler’s smart folders. From the post:

I wanted a simple, friendly GUI to a database of thoughts and ideas that was also a writing tool; in essence an easily searched, easily edited journal that would allow me to attach images and other media. I wanted this note manager/snippet collector to be scriptable (what else, coming from the editor of these pages?). I didn’t need a powerful (and expensive) database manager like DEVONThink; but I did want an elegant, inexpensive ($25, fully-functional demo), middle-of-the-road application for storing virtually anything and recovering it with a simple search from either its user interface or from a script.

Adam found Journler to be the right tool for the job and recommends MacScripter readers to give it a try. Adam also points to MacScripter’s Journler category as a repository for Journler Apple Scripts and suggests that interested users have a look at Journler’s own AppleScript and Automator forum. Check out enough of the posts there and you’ll stumble across Adam’s own extensive contributions made under the username NovaScotian. Be sure to say hi!

It’s over a week since WWDC 2007 and I am still reeling from my first exposure to the fascinating, jargon filled world of software development processes. What was probably a boring session for many of the attendees was for me a first step into the disciplines of project management and development methodology. I am eager to apply what I have learned.

Lex
Alongside Journler I am working on Lex. Lex picks up where Journler leaves off. If Journler is “entry based information” then Lex is project based documents. Journler was originally designed for journaling your life. Although the program benefits from recent features seen more commonly in information managers, Journler is not one by its nature. Lex is, and where Journler runs a single database, Lex is databases plural so that you can split projects up and deal with the relevant data in distinct groupings.

Development has, however, taken longer than expected. In a post two months ago I said I would need four weeks to produce a working version. It was a naïve enthusiasm. The coding itself isn’t so much the problem. My style is. I go about my work in an erratic way, jumping between features to see if they are all possible. I have reached a point where, although I am confident everything can be done, I am lost in a maze of half accomplished ideas.

Iterative Development
“Iterative” software development refers to a process which moves forward in short, repeated, independent phases. The steps involved in the development of a complete product — requirements analysis, design, coding, testing, and documentation — are compacted and micro-applied to every change made over a product’s lifetime. With each completed change an improved, fully functioning product is ready for release, even if it is not actually delivered.

I have decided to apply this approach to Lex. It is an opportunity to discipline my practice and ideally produce a better product faster. Hoping to add to iterative design theory, I will be adapting the process to fit the needs of this project. Rather than applying the iterative method to small changes built into the project as a single system, I am partitioning Lex into self contained, feature specific “proxy applications” and applying the iterative process there. The goal is to produce independent, fully functioning applications out of the many features that Lex brings together.

The Proxy Application
I am calling them proxy applications because during development they stand in for the corresponding features actually built into Lex. This differs from prototyping. I will not be developing models that demonstrate or test an idea. Instead, the process should produce applications, feature complete though highly focused on a single task. By isolating a subset of Lex’s functionality into a separate application, the proxy allows me to analyze, design, code and test that subset independent of every other. While one proxy undergoes real world testing I’ll be able to work on others without interfering with the first, and vice versa.

Lex is an extensible application from the ground up. Although I define the program’s core functionality at the outset, plugins are responsible for the actual implementation. Lex itself is tiny, a simple structure with hooks for the plugins. I believe that projects of this nature are especially suited to the use of proxy applications. Most of the proxies I have envisioned for Lex are simply wrappers for a feature expressed by one of the hooks.

Applying the Method to Lex
If this is all too abstract let me offer a concrete example. In addition to the regular and smart folders already familiar in Journler, Lex allows you to build spotlight folders which automatically collect documents on your computer. Support for executing this action is built into Lex, but the means by which you specify a folder’s criteria is implemented with plugins. This is the hook. Lex examines the document type targeted by the folder, e.g. PDF or Image, and loads the most appropriate plugin, permitting plugin developers to target files with custom metadata or taylor the existing set.

Spotlight folders concretely define one of Lex’s features. Following the proxy strategy, I isolate the relevant code and wrap it inside a proxy application. The proxy takes center stage during development. I do all my design, implementation, and testing on it. Furthermore, the proxy is a complete application in itself. In this case I’m calling it Smarts. As soon as Smarts reaches a mature stage I intend to release it as a standalone application. Real world testing will verify that the feature performs as expected, at which point I can integrate the code back into Lex itself.

Where It All Leads
From the user’s perspective it will look like I’m not working on Lex at all. Instead, you’ll see the release of a number of simple applications with strongly defined feature sets. But behind the scenes I am actually combining each verified proxy into a single, whole application: Lex. The method should allow me to establish the code for each feature more quickly as well as more efficiently test and debug it. Ideally, before a beta of Lex is even made available, most of its functionality will have been tested and verified. The end product is one of higher quality that is produced more efficiently.

That’s the hope. Lex has just become an experiment in software development. It’ll be interesting to see how this works out.

Or: It’s the Content, Stupid.

Had a good conversation today with Chris Messina of Citizen Agency fame. Chris is one of the Agency’s co-founders and advises startups and other firms on their web presence. He is steeped in Web 2.0 goodness and is enthusiastic about the iPhone’s potential as a device which supports web standards. Our conversation brought into perspective my recent diatribes against the iPhone and has given me the chance to ask, is it really that bad?

Let’s take it by way of the WWDC’s OS X Graphics and Media State of the Union. I can’t go into details because of an NDA that was signed by my presence, but let me say that the session offered a convincing argument for the unification of the web, desktop and mobile experience, especially by way of “rich” — read media rich — content.

Since the desktop PC became a consumer product we’ve seen it increasingly decentralized. What traditionally belonged on the desktop is now appearing on other platforms. The transformation has given rise to a “device ecosystem.” Consumers work on their desktops, give presentations with their laptops, play on their portables, listen to their iPods, stream movies to their Apple TV and surf the internet on their mobiles. At the same time two other trends have developed. Rich content has become more prevalent, and individuals expect a single, unified experience.

The circumstances have led to a bit of a conundrum: how do you deliver the same experience when every year the experience becomes more complex and the devices which deliver that experience more varied? Take a movie for example. Alongside that movie are a website, a soundtrack, games for your desktop and portable, downloadable trailers and eventually the movie itself as a download. Heck, you might even throw in email stationary. Not to mention that presentation you put together on your desktop but can’t access from your laptop because of a bad USB stick, but which should be available from your homepage, usable on your phone and editable on your co-worker’s Vaio. What’s the solution?

Standards, and it is here that the iPhone may offer something truly revolutionary. It’s not an area I am well versed in, so I missed it the first time around when I said in my keynote post:

“Instead of announcing an SDK Jobs announced that developers would be able to write AJAX Web 2.0 applications that could be run directly in Safari on the iPhone. This was even billed as an advantage — developers wouldn’t need an SDK, how great is that? But the phone has a standards compliant browser. Of course it can run web apps based on dhtml, css and javascript. Nothing new here.”

Ok, nothing new because we knew the iPhone runs Safari and Safari is standards compliant. But that the iPhone is a phone with a standards compliant browser in the first place is huge! The sessions zeroed in on this with examples of how web pages render on the iPhone verses other web enabled devices. Correct me if I’m wrong but I believe Apple Inc. is the first company to fully support web standards on a mobile device so that a site’s content appears exactly how it appears on your desktop or laptop.

With that we reach the point of this article: the platform is becoming irrelevant. At the end of the day does it really matter what kind of computer or device you use as long as it enables you to do what you want and in the manner you expect? The western consumer is about to enter an age of ubiquitous computing. I love that word, ubiquitous. Your Mac better play nice with the PC at the office and they both better work with your printer and your phone, render web content uniformly and allow you to access your data from anywhere at anytime.

I’m sure you’ll forgive the developer if he or she is upset about this. When Steve Jobs takes advantage of his Keynote to flip 6000 Macintosh developers the bird, hand delivering instructions to start writing web apps, he is negating tens of thousands of years worth of career and experience. I’ve only been doing the Cocoa/Obj-C gig for a few years now, but there are developers out there who have been doing this for a lifetime. Asking them to consider a whole other programming language with its syntax, style, libraries and quirks is like telling a Manhattan taxi driver to do his job in LA starting eighteen days from now. You’re gonna hear a few choice words.

Chris is hopeful this is a step in the right direction and our conversation really opened my eyes. It’s going to be a lot of work for Mac developers to make this transition but it certainly looks like a necessary one if they want to be relevant in the approaching age of ubiquitous computing, platform irrelevancy and content supremacy.

If you haven’t yet heard the Delicious Generation has become a hot topic in the Macintosh community. It’s a title bestowed upon a new generation of developers inspired by the appearance of Delicious Library. Other apps like Disco and iClip also come to mind. I was afforded the opportunity at WWDC 2007 to mingle with the members of this up and coming group, a generation X so to speak and one that will play an increasingly prominent role with the release of Mac OS 10.5 Leopard. For my second WWDC post I’d like to characterize the Delicious Generation and offer a caveat or two.

Rock Star Programs
The Delicious Generation has a style, and it is Rock Star Programming. I’m not talking about a methodology here like “cowboy coding” or a paradigm shift made possible by new features in the latest, baddest cat on the block. I mean an attitude both personal and technical. It is a way of doing things and having things done which has developed in and around the programmers and the applications they create. These guys — and it is mostly guys — are rock stars of the Macintosh world. They rock, their apps rock, and they know it.

Rock is an ambiguous word but the metaphor is entirely appropriate. On the application side, rock star programs “do it because they can.” In a word it is show; rock star programs put on a helluva show. They may not be all that incredible, sometimes just a three chord progression, but rock star programs know where to play the extra rift, hit the impecable triplet or hammer on and off, and all with perfect timing. Rock star programs take the most mundane data management tasks and make them gorgeous and exciting.

Rock Star Programmers
Rock star programmers throw a concert you want to see in the next town and then again, and indeed rock star programmers have their groupies. The fans gather online, hanging out at Digg, de.licio.us, twitter and flickr, but they get together for parties too, private rock star parties. WWDC featured the one or the other. You see, rock star programmers know they’re good, and when you’re good you’re exclusive. It can’t be helped.

Don’t get me wrong. I met a few of the rock stars this week at WWDC and they’re good folk. Sure, there’s the über rock star who takes the mic at Q&A, introduces himself with “Hi my name is so and so from so and so, you may have heard of it,” and then talks for five minutes to the applause of his fellow developers (!). But most of these guys are cool, down to earth rock stars, smart guys writing killer code for awesome apps. Props. On stage these guys rock, but back stage they just want to chill, drink a beer and talk.

Rock Star Leopard
Rock star programming is nothing new. The programming community has always had its personalities, coders with style and code on the edge. But Leopard heralds a new era. Leopard is the rock star’s OS, enabling a heretofore unseen level of visual appeal and interface excellence. We’re talking some serious snaz here. Apple has given developers a whole new toolset, a repertoire that coders and designers will take advantage of to deliver an immersive computing experience that is dynamic, fluid and potentially ubiquitous. Folks, your Mac is about to get a whole lot better. “Wow” doesn’t cover it. The volume has been jacked up and the set is gonna blow your mind.

This time around we are talking about a paradigm shift, and as is often the case with paradigm shifts there will be those who try but for whatever reason are unable to hit the mark. I can think of two. Put the power chord and effects box in the hands of a noob and you’ll get a cool sound now and then but also a lot of noise. Leopard enables but with that enabling come the results of inexperience and excess. Both new and longtime Mac developers will be trying new things with the interface and, failed by Human Interface Guidelines (the HIG) that are long out of date, much of what they produce will be ugly. As I’m sure you know, a lot of rock is shit.

Another problem is the level of knowledge and talent required. Rocks stars form bands for a reason. The dude on the piano singing into a mic has a good sound and sells a lot of records, but he doesn’t rock. If you want to rock you need a drummer, a guitarist and singer, your buddy on the ukulele and someone else on sax. Putting on a show with substance requires personnel. The Mac OS already offers a plethora of technologies. Leopard adds to the list. The lone developer might be an expert in one or two areas but he or she can’t be an expert in all of them. While new technologies like CoreAnimation do make it easier for that lone developer to rock, the most rocking apps will likely be written by teams of talented individuals, however loosely associated they are.

Rock star programming and the delicious generation are already underway in full force. If you’re impressed now, wait and see what October produces.