Wednesday, March 24, 2010 at 5:48AM Is the perceived value of a Kindle book greater than that of a hardcover?
;)
This pricing taken from Michael Lewis’ The Big Short.
Kindle, digital books in Commentary Wednesday, March 24, 2010 at 5:41AM I can now reveal that the product I’m developing is called Sitely. The Sitely teaser site is now live.
Sitely in Commentary Sunday, March 14, 2010 at 5:40AM 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.
FutureHouse, Software Development in Commentary Monday, February 15, 2010 at 10:52PM 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.
speculation in Design, Hundred Year UI
The Sitely Story
“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.