pursuing possibility by Loryn Jenkins

Endurance and Perseverance Required

2011-01-17T11:02:40Z

My Pathfinder Club returned from the Under Oath Camporee a week ago.

When the Camporee quickly deteriorates from a brilliantly sunny opening parade to torrential rain that turned the camping area into a mud-pit, it takes a special willingness from the members of the club to endure and persevere.

Willingness to eat breakfast while standing in a 30 ml river flowing through our cooking tent.

Willingness to slosh through 60 ml of mud every step you take outside your tent.

Willingness to carefully sit at the entrance to your tent, remove a mud-encrusted boot, carefully wash the leg from the knee to the foot, then dry it, and carefully retract it inside the tent; then repeat the performance for the other leg. And be willing to do this every time you re-enter the tent. (This procedure becomes particularly painful when you’re forced into a midnight excursion to the portable toilets.)

The good news is that my Pathfinders proved that they indeed have the mettle to endure and persevere in difficult conditions. We belonged to the minority of clubs who managed to feed, clothe and sleep their Pathfinders on the hill.

The Under Oath Blog does a good job of documenting Camporee conditions.

View from my window

2011-01-03T19:17:18Z

View from a farmhouse west of Murwillumbah, NSW, Australia.

For some reason, SquareSpace’s iPhone posting tool didn’t publish my text along with the image when I first published this photograph. What follows is my recollection of what I wrote.

Today I drove from Sydney to west of Murwillumbah. I’m staying at a farmhouse this evening. Tomorrow I’ll travel to Toowoomba, Queensland.

I’m leading ten teenagers on a Pathfinder Camporee, where 2,500 teenagers from around Australia are gathering for a six-day program full of physical challenges and spiritual nourishment.

2010 Article Review

2011-01-01T19:42:00Z

What I write on this blog has been largely determined by several focii I set it when I began writing the blog in mid 2009:

Improving the world through use of knowledge tools
Reviewing knowledge tools
Designing and Creating new knowledge tools
Analysing the way the world works (analytical tools in action)
Software design trends
Software criticism
Professional practise notes

These are the topic focuses set in the left-hand pane of my Career Daybook article planning system. (The Noguchi shelf sits on the right, providing a time-ordered representation as to what I’ve touched most recently.)

I have not at all been disciplined about which of these topics I write about. Rather, I’ve written whatever has most demanded my attention. So, having written primarily for myself, I find it interesting to see what articles have been most read.

Goal Review

In looking at the articles published since 2009, I find that I haven’t been publishing on the full range of topics on which I set out to write about. Moreover, my Noguchi shelf contains stubs for 117 articles that I thought about writing, but haven’t found the time to actually write.

So that leads me to publish some New Year’s resolutions.

New Year’s Resolutions

Exercise more.
Blog more.
Blog more regularly.
Blog on topics that better represent my underlying interests.

Every Ending Represents a New Beginning

2011-01-01T12:09:41Z

Today I had the unfortunate task of closing down the last internet services provided by Future House. The website editing and hosting services known as iiab and Sitely have had their services switched off.

Over the course of the last few months I became the final employee of Future House, the company once known as Geekdom. When I joined in Geekdom in 2009, there were 86 employees. As of today, Future House now has no employees.

During the first part of 2010, I was so focused on building Sitely that I omitted blogging. In the second half of 2010, I didn’t feel able to blog about what was happening within the Photon-owned that employed me, due to the level of uncertainty surrounding what was happening within my company, and that level of uncertainty surrounding Photon’s recapitalisation.

Later in January, I’ll publish my account of the challenges and achievements of the team I had the privilege of leading during my employment with Geekdom / Future House.

Happy New Year to you and your loved ones.

The Sitely Story

2010-05-16T21:02:11Z

“A website for every business,” is the rallying cry that drove the vision and development of Sitely. Here in Australia, only 56% of businesses have a website. Our vision is for every business to have a website.

So we set about creating a service to eliminate every barrier between businesses and the websites they need:

Cost - Sitely is free. (An optional paid version is coming.)

Technical skill - Sitely requires no knowledge of tags or HTML. It is completely WYSIWYG. And requires only that you know how to drag things around a screen, and click to edit.

Design skill - Sitely comes with a (growing) range of industry-specific designs.

Writing skill - Sitely generates a site complete with industry-specific text that is customised for the business.

Time - Sitely builds a website instantly.

In less than five minutes, any business owner can sign up for a Sitely site and have a website generated specifically for them. They can select from a range of designs, or set about customising their own. They can tweak the content, add or remove pages, and publish when they’re ready.

And while we’ve focused heavily on the first five minutes of use, we’ve spent even more effort thinking through the lifecycle of creating, modifying, editing and the on-going maintenance of websites. Sitely is a website development tool you can use on a long-term basis.

Sitely is now in beta. We’ve aimed really high, but we know we’ve more work to do. We’d welcome you giving Sitely a try, and are keen to receive your comments on how we can better nail this vision.

Are Kindle books more valuable than hardcovers?

2010-03-23T18:48:13Z

Is the perceived value of a Kindle book greater than that of a hardcover?

This pricing taken from Michael Lewis’ The Big Short.

Sitely teaser site

2010-03-23T18:41:15Z

I can now reveal that the product I’m developing is called Sitely. The Sitely teaser site is now live.

March update

2010-03-13T18:40:21Z

I get a real buzz whenever we ship software. It’s the high-point of software development, and the payoff to the software development rhythm.

The early product planning, architecture and design choices involve a lot of thinking, research, discussion and debate. Progress seems slow, but the questioning is essential to later success. Early implementation often seems to stutter, as the entire team figures out what the design really means. Then implementation moves into overdrive as things become clear. Rapid progress is made. And then there is the final integration and testing of the software. Testing is a rapid-fire, full-contact sport. The team pours on the effort. Then you hit that magical threshold where you see the bug count decline rapidly even though you’re pouring on the testing. And you know you’re close to shipping.

The last few weeks have been incredibly busy. We’re well into the late implementation phase. The entire team is palapably excited about seeing our product take shape, and then shipping it to market.

At our company-wide meeting on Friday, our Head of Marketing, James Anderson, unveiled a new company name and identity. We’re now known as Future House. We have a product name and identity chosen, but that’s being announced in a few weeks.

On the development team’s wall is a project status sheet. Every time we complete a module, we color its box green. The rate of boxes turning green is accelerating.

I’m extremely excited about this development. We worked really hard on the architecture, infrastructure and design choices for this project. A lot of our choices have been appropriately conservative. But we made one or two bets that we think might pay off. We’re right on the cusp of seeing payback.

And my engineering & operations team have also been incredibly busy. Development teams attract greater fanfare, but in a SaaS platform, the discipline and foresight and skill of an engineering and operations team are critical. They’ve recently been focused on preparing the infastructure for our new offering, significantly reducing existing infrastructure costs, and performing some robust analyses of our reliability data which will result in new tools, practices and processes in order to make our new offering highly reliable.

As we power through the remaining development, integration and testing, the level of excitement within Future House is growing. We’re looking forward to sharing with you what we’ve been building.

Save, an historical oddity

2010-02-15T11:52:40Z

Last year, I was teaching a group of 10-15 year olds about the history of computing. The kids were pretty familiar with the technology, mostly knowing what CPU and memory and storage are. What really amazed me, though, was the universally-blank expressions on their faces when I mentioned “floppy disks”. These kids were all born (1994-1998) right at the time when floppy disks became extinct. As a result, they had not a clue what they were. Unless you directly step in to educate the next generation, knowledge can be lost between generations pretty quickly.

The save button will be one such historical quirk.

By the time my group of teenagers manage to raise their offspring to teenagehood, *they* will have to explicitly teach their children about the “bad old days” when documents needed human action in order to save. They will tell heroic stories about redoing work due to blackouts or pulled power cords. And their children will sit there dumb-founded: “Computers used to lose information?”

It was only ever a performance hack that caused software developers to require users understand the difference between volatile and non-volatile memory. Other than image and video editing apps, it’s not technical limitation that causes the perpetuation of the save button; rather, it’s cultural inertia of software developers that preserves the save button. After all, Apple’s iPhone and iPad devices already hide the difference between RAM and flash; developers of productivity applications will soon borrow the concept. There’s sufficient computing resources to do this right now, for most apps.

The manual save mechanism on desktop apps will not outlast the generation of programmers who, as children, grew up using iPhones and iPads.

When you implement continuous, automatic autosave, you also have to provide a generous undo mechanism. After all, people still make mistakes; or explicitly rely on these mechanisms to experiment.

The session-specific undo mechanism will soon give way to persistent undo mechanisms. Applications will begin to universally implement journalling and automatic versioning to support persistent undo. They will enable the exploration of multiple time-points in the versioning history using multiple representations, transition effects and graphical slide-based timeline metaphors. (Think of app-specific Time Machine functionality.)

Furthermore, in addition to a purely linear undo mechanism, developers will analyse the independence of objects within their programs, using it to implement object-specific undo and version exploration mechanisms. So in a text editor, I’ll be able to select a paragraph and have it show me the half-dozen major variations over the last n minutes/hours/days, regardless of when I edited that paragraph.

Now, providing these features introduces a certain complexity to programming. You might ask how this fits with my assertion that programming productivity will only increase relatively slowly. These mechanisms will be provided by a combination of patterns, frameworks and the use of appropriate database technology. (Ironically, today’s database technology is frequently the reason database-centric apps frequently fail to implement undo.) In the future, the persistent store will provide the framework for journalling and versioning, for both single-user and multi-user environments.

Having these mechanisms on hand will enable independent developers to inexpensively include these “advanced features” in their apps way, way before we even get close to the Hundred Year UI.

Source: To my knowledge, Petter Hesselberg’s Programming Industrial Strength Windows first proposed getting rid of the save mechanism. He also makes a strong argument for changing Save As into Archive, whereby the newly-named archived copy is the *other* document (not the current one), reversing the conventional behavior of Save As and, in so doing, providing much better UX.

Searching for the Hundred Year UI

2010-02-14T19:00:00Z

Of the many thought-provoking essays written by Paul Graham, his Hundred Year Language thought experiment has always struck me as fascinating. Unlike Graham’s conclusion—in which he concludes that a language described in 1958 would provide the basis for the Hundred Year Language—I think user interface design provides a wide scope for invention and reinvention.

What’s inspirational about Graham’s challenge, is his notion that perhaps by looking out a hundred years, we can begin adopting approaches that will prove to be fruitful in moving us toward the hundred year mark right now.

How could we possibly see a hundred years out?

It’s important to remember that the GUI is 30+ years old. The visionaries who foresaw our present—Vannevar Bush, Douglas Englebart, Ted Nelson, Alan Kay—needed a view that stretched 40 to 50 years in advance of the state of art. If they could see to the 40 or 50 year horizon, why shouldn’t we, equipped with additional information drawn from the history of computing, aim to shoot for a hundred? By combining our historical understanding with a creative vision, why shouldn’t our vision reach ahead that far?

Principles in our search

I would like to propose some principles that should stand us in good stead.

Human cognition will change only gradually over the next hundred years. Jakob Nielsen reports that conclusions from interaction research performed twenty and thirty years ago are still valid. There’s no reason to believe these results will change (much, if at all) over the next hundred years.
Culture may change significantly. Any study of modern history demonstrates the significant cultural changes that can occur over the course of a hundred years. Whether that is due to economic, industrial, technological, political or philosophical causes, cultural attitudes and outlooks can change substantially.
Technology development will continue unabated. Unless our economic system is systemically interrupted by drastic events (think: peak oil), technological development will increase the capabilities of our machinery to virtually unimaginable levels. (Paul Graham’s thought is that the lower bound of computational performance over the next hundred years is a million times faster. Now, he might be able to imagine that, but I’d consider the experience of a million-times faster computer to be virtually unimaginable. Let us try, though.)
Programming will still be hard. Fred Brooks won’t be disproven in the next hundred years: there will still be no silver bullet. Programming is an unnatural act—asking humans to be purely logical when we are designed for emotional response—and the rate of progress in programming productivity won’t be any greater than that demonstrated by the last thirty years.

As we progress on this search, we may very well decide that there are other principles we can treat as axiomatic. When we do, it will mightily assist our capacity to envision the future.

Now let’s get creative! How about joining me in envisaging what our UIs may be like in a hundred years?