From: Benjamin Northey
Sent: Sunday, 22 November 2009 11:32 AM
To: Andi Herman
Subject: Re: Thank you
So kind of you to share this with me. Jake was pretty much the highlight of the week for us! The orchestra loved him and as you say, to see such pure joy was very special indeed - very moving. Loved reading the blogs also.
I hope that this is something Jake will remember for a long time. Please say hi to BOTH of your children from me!
all best, Ben
Friday, 20 November 2009
Tuesday, 17 November 2009
Girl: I'm going to see Taming of the Shrew.Friend: Is that like the book that's based on the movie Ten Things I Hate About You?Girl: Not quite. It's by William Shakespeare.Friend: Didn't he do Romeo and Juliet?Girl: That's the one.Friend: So he writes books about movies?Girl: Have you ever been to English class?
Friday, 13 November 2009
- Big - little
- Black - white
- Hot - cold
- Fiddle - middle
- Hot - cot
- Head - said
- Ella: Tall - small
- Andi: Happy - crappy
- Andi: Sad - glad
- Dan: Familiar - unfamiliar (deemed unacceptable)
Sunday, 8 November 2009
Monday, 26 October 2009
All of this has been bad for my Kibitz blogging, although I have been contributing to a new blog all about our emerging visual collaboration product: bCisive Online:
Thursday, 14 May 2009
- How can the sales manager get an effective overview of all open opportunities? And then drill down.
- Similarly, how can an individual salesperson get perspective of all his opportunities in order to better gauge where and how to focus effort?
- How can a sales manager customize the qualification process to fit her team's needs?
- How can a sales person or manager share insights with other team members, or present a pitch to clients?
- Excellent: The upper right contains the best-qualified, highest amount opportunities
- Safe bets: The lower right are well qualified, lower amount opps
- Pie in the sky: The upper left contain the high amount, not yet well qualified opps
- Poor: The lower left contains poorly qualified, low yield opps
- In the image above the line of small circles on the vertical axis are unqualified opportunities. Why haven't they been qualified yet?
- Large circles in the left quadrants reflect opportunities where a lot of effort is going in without much progress. Some of the "pies in the sky" may be worth persisting with (for a while), but the "poor" opps need to be quickly qualified across or dropped.
Thursday, 16 April 2009
I think that this is a good model for software development in software start-ups.
Priority one: Build something that people want, fast
The main risk in a software start-up is making something that people don't want. So you want to find out whether your initial idea has merit, fast. So -- if at all possible -- you build a small prototype, and test it out in the marketplace, fast.
In order to satisfy the need for speed, you cut a few corners, and because it's small (and your team is good) you can get away with this approach (for now).
If no-one wants your prototype, you scrap it, and you haven't wasted time on lots of process that was supposed to pay off in the long-run (because there is no long-run).
On the other hand, if it the prototype is promising, you will learn from the market feedback how to make it better, and it will start to grow. This is where it is critical to switch gears and slow down (at least for a while). Because if you do not, you will find yourself in the realm of cowboy development, the bugs will start to bite, and the pace of development will drop as your team gradually spends more and more time debugging, less time developing, resulting in a drop of confidence -- "I don't want to quickly make this change because it might break something" -- and loss of tempo.
Priority two: Restore quality (and sanity)
The alternative is to switch modes. Fred Brooks said "build one to throw away", but at a minimum you should review what has been done to date and investigate and prioritize the very real risks of continuing with a prototype. These might well include:
- Customer or prospective customer loses data or has it corrupted
- Customer or prospective customer experiences bugs, crashes, or loss of service
- A crash or a bug during a demo
- The software does not scale, so performance degrades over time
- Development slows so that critical new features can not be delivered in a timely fashion
- Pair programming: Two heads are better than one, plus it offers real time code reviews, mentoring, camaraderie and friendly competition, less web-surfing
- Test-driven development: Writing automated tests clarifies the design and as they build up offer an early warning system when a change breaks something unexpectedly (Design by Contract gives similar benefits)
- Continuous integration: Frequently "checking-in" and automatically running the automated test-suite identifies incompatible changes made by different programmers or pairs sooner rather than later; saves you from merge hell
- Refactoring: By reviewing code, eliminating duplication, reducing coupling, and improving the use of abstraction, your software base will become more concise, readable and maintainable
- Short iterations / planning game: By maintaining a list of feature requests and bug-fixes that the developers estimate and the internal customer prioritizes (within a budget based on the amount of work accomplished in the previous iteration), a sustainable rhythm is established, and healthy prioritization is forced
- Sustainable pace: Working more than an eight hour day / forty-hour week leads rapidly to damaging the code base, loss of morale, and bull sessions as people are present in body, but not in spirit -- avoid the "Death march" scenario
For a web-based service additional infrastructural elements and diagnostics should be reviewed and added.
All of this is manageable as long as the prototype is small, but the longer these steps are delayed, the greater the costs that must be paid. It's a lot like going into debt. You not only have to repay the loan, but also the accumulated interest. Some people call this design debt. (And the interest rates on design debt tend to be high.)
And then the cycle turns
While making incremental changes continued agile iterations is probably the way to go, slow and steady (but not slowing down). When the time comes to make a leap forward, knocking up a quick prototype is a great way to vary the routine, and makes business sense.
Almost everyone who learns to program first experiences the joys of "cowboy development" on small personal projects, but when they "turn pro" or start working on larger projects they soon learn that it doesn't scale beyond what you can easily hold in your head.
Some people think that up-front design and analysis will save the day, but this leads to waterfall with its 1/3 design, 1/3 development, 1/3 testing rule-of-thumb when done well. But then you discover that the requirements were wrong (they always are), and another long iteration is required.
Smart people rediscover short iterations, and lately these have been articulated as Agile Methods, and also include other ways to make the computer (e.g. automated tests) and human nature (e.g. pair programming) work effectively and more satisfactorily. The cost is a bit of deferred gratification by having to do some things up front (e.g. writing tests, refactoring) that pay off over time.
However, it would be wrong to say that an Agile approach is the best for everything, at every scale. In particular, in knocking up a quick prototype one may well be justified in reverting to some of the cowboy practices for a short period. Note that it is not compulsory to drop all the agile practices when doing so -- do what suits the situation.
The tricky bits are:
- Not leaving it too long
- Paying off the accumulated technical debt
- Getting back into the discipline of following the practices
- Combating the likely organizational pressure to continue at the previous pace!
*My esteemed colleague -- and former Olympian -- Ben Loft points out that interval training may offer a better analogy, but the name isn't as memorable.
Sunday, 12 April 2009
Whereas solution-selling salespeople listen for “pain points” that the customer can clearly articulate, provocation works best when it outlines a problem that the customer is experiencing but has not yet put a name to. -- from the articleBut Solutions Selling has a powerful way to think about where your customer is at, before getting into "pain points": Levels of Need*:
- Latent need: Unaware of a need that could be satisfied by purchase (perhaps they are unaware that there's a problem, or in denial, or resigned to coping with the status quo)
- In pain: Aware of the need ("in pain"), but unaware of how your offering can help
- Vision creation: The prospect has a vision or a "Solution", ideally including your offering.
Tuesday, 7 April 2009
Seriously: When prospective customers see the Qualify tool -- part of Austhink's bSelling add-on to Salesforce crm ...
they say two things:
- Can I customize it?
The second reaction -- the wish for customization -- is natural. Although at Austhink we believe that the out-of-the-box system is quite generic, sales teams do of course vary in their terminology, types of customers, and overall slant sales.
So, I recommend a suck it before you salt it approach:
- Try out the generic version (that comes with the free version of bSelling) on a few opportunities to get the feel for the process. Just pick a neutral "card" if a factor doesn't seem to apply.
- Make notes about where the terminology needs revision, which "factors" don't apply, and which (if any) are missing.
- Upgrade to the premium version of bSelling and make use of our soon-to-be-released customize feature.
- If you need extra help, we can arrange consultation!
Each line represents a deck of cards in the tool, and each block represents a single card. The length of each line represents the weight of each factor. You just click on a box to edit some wording (shown), or click on an end box to stretch or squash a line (to make a factor more or less important compared to the others). Other operations are similarly simple.
By the way: If you think of the Qualify tool as a level in a game, the customization tool is like the level-designer that allows an obsessed user to design new game levels for their friends to play. In this case, the customization tool allows the sales-manager to tweak (or totally revamp) the qualification process to fit local conditions, and better monitor (and mentor) the sales team.
We are about to trial the customization tool with a select group of beta-testers -- email me at email@example.com if you want to give it a whirl -- and the first version should be available in the next week or so.
Friday, 3 April 2009
Sunday, 15 March 2009
Here are some brief notes about the product (a visual tool to enhance the performance of sales teams), its placement (as an add-on to Salesforce CRM available through salesforce.com's AppExchange), and the development experience (using Adobe Flex + Django talking to Salesforce).
The best way to get a taste for this add-on, which helps the salesperson to better Qualify (i.e. estimate the percentage chance of closing the deal) , better understand the customer's pain(s), and ultimately pitch more effectively to the customer's needs -- is to check out the 2 minute (approx.) introductory video:
For non-sales people, here's my distillation of Solution Selling, one of a family of consultative approaches to sales -- along with SPIN, Strategic and Consultative Selling -- that bSelling is intended to support.
Austhink's Softwares previous products, bCisive and Rationale were PC-based and intended to create new markets: Rationale for improving Critical Thinking in education, and bCisive for applying Visual Thinking to business.
For our first web-offering we decided to pick a more targeted application -- consultative selling -- and apply our visual approach more narrowly. This enabled us to go from "let's port bCisive to the web" (a daunting undertaking on account of the size of the pre-existing product) to "let's port the bits of bCisive that will help with consultative selling" (a smaller and more customer-centric) undertaking.
We aimed from the outset to put the resulting application on Salesforce.com's AppExchange, as a way to make bSelling visible to our chosen market segment, and to offer easy integration with the leading web-based CRM.
We accomplished this with a team of 3 in just over two months, admittedly making use of some initial work on a web-port from last year, plus our accumulated experience from bCisive, Rationale and some earlier non-commercial web-based projects, most notably Aaron's side-project, Path of a Hero.
We found that Adobe Flex / AS3 gave us the graphic power (and portability across browsers) that we wanted for the front-end, with our architecture hanging off a slightly souped-up version of the PureMVC framework. We use Django / Python / MySQL for the back-end and use AMF3 / PyAMF to get fast communication between the back and front-ends.
The big unknown for us was integration with Salesforce CRM. It turns out that their APIs and docs are pretty good, and we were able to embed our app as a web-page in their S-Control.
Now, it is possible to build apps entirely on their force.com platform, but we chose not to because:
- It required a steeper learning curve
- We had a pre-existing technology investment
- It would couple us completely to their platform
One note for start-ups: There is normally a $US5000 application fee for the review (annual!). The two ways to waive this are to develop directly on the force.com platform (i.e. inside the Salesforce sandbox), or to supply a free version of your app. We went with the free version.
Compared to the security review, the final review was less demanding.
We are putting the finishing touches on an "export to PowerPoint" feature for the paid version, so that a salesperson can grab some snappy visual slides to supplement customer presentations.
Naturally getting the word out is paramount -- thanks to AppExchange we've already had some people checking out the video and installing bSelling-- and we look forward to responding to customer feedback with further refinements. To this end we have set-up UserVoice to help out with this. The AppExchange infrastructure requires people to leave details, so we will also follow up (selectively and politely) with some of the early adopters to find out worked and what didn't.
Beyond bSelling on Salesforce we are also look at integrating it with other online platforms (SugarCRM is an obvious candidate).
And beyond that lie other applications in Sales and other business verticals. We aim to apply our skills and technology to create other "Enterprise 2.0" apps, but in these -- ahem -- challenging times we need to be strategic about picking off targets.
Friday, 13 March 2009
Which super-heroes do you play?"I am always Captain Balding and Max is always Captain Underpants.", says Jake.Intriguing. What is Captain Balding's super-power?"We have different powers every time, but one power we always have is super-phones."
With these two heroes to protect us, we simple townsfolk can again sleep safe at night ...
Wednesday, 11 March 2009
When a stranger broke into Silicon Valley executive David Prager's house yesterday, he did not call police or reach for a gun - he logged on to Twitter and set up a live video stream.So there you go: Another D. Prager -- other than Dennis -- in the news.
Read on ...
Friday, 20 February 2009
- Sport, "and finally:"
- How to draw,
- That [another child] is not my friend, and
- That I do not know how to draw.
Wednesday, 18 February 2009
The other night I swallowed my pride and started to work through HtDP (How to Design Programs), the PLT Scheme gang's reaction to the fact that SICP (which came from MIT) while great for the suitably talented individual does not by-and-large work for the mainstream. In this book they explicitly teach program design, a systematic approach to thinking and problem-solving that it seems only a few people get by the more traditional osmotic process.
HtDP is covers a great range. Although principally geared to college level, it can be taught in high schools (at a slower pace), and can teach most experienced practitioners more than a thing or two.
Additionally, the people on the PLT Scheme mailing list are incredibly friendly and supportive. Here's what Matthias Felleisen, first author of HtDP (among many other things) wrote when I mentioned that I was starting to work through HtDP, but was having difficulty restraining myself from skipping ahead:
If you are an experienced programmer, you should read HtDP like this:In short: Great tools, great teaching materials, supportive and experienced community.
I expect that somewhere around late part II, you will slow down. You may pick up real reading as of part III, though some may make it thru III and only "stutter" in IV.
- Read the sections whose title starts with "Designing ...."
- Also read the "iterative refinement" sections
- Pick five exercises in the preceding and/or follow-up section and solve them according to the recipe
- Unless you're stuck move forward
- Try to understand the "symmetry" between data definitions and templates
And holler if you are having trouble -- Matthias
- Use check-expect to express your examples/tests
- Avoid draw.ss exercises, replace them with world.ss but that's a non-trivial switch
Working with someone from a complementary design background helps to trigger creative sparks. David has pointed me to this article by Nate Fortin about the non-separability of design into different disciplines in Cooper Journal. Cooper Journal is hosted by Cooper Design, whose principal Alan "Father of Visual Basic" Cooper wrote the influential book About Face, and the provocative and important The Inmates are Running the Asylum, both of which I also highly recommend.
One of the issues that we are grappling with is how best to engage expert outside design consultants like David. At the moment we are doing a blend of some consulting time, plus directed tasks, spread out over time. The benefit of the spreading out is that we get the benefit of David's creative input early, when it can have a formative effect, and guidance at later stages too as the product becomes more "locked down". Coordinating our schedules is a "fun" part of this approach, and is of course more challenging than just employing him for confined blocks.
Finally, if you want to commission David, I would love to link to his web-site, but I believe that it is not ready for public consumption just yet (hint, hint ;-). In the meantime, David can be contacted on email at firstname.lastname@example.org.
Monday, 16 February 2009
We use our skills in software, game design and visual animation to make our customers' business applications more fun (and much more effective).down to a snappy under-five-words tag-line.
Here is an unfiltered list that I came up with while sitting through a talk on "cloud computing":
- Make work fun
- Make work visual and fun
- Make work fun and visual
- Work as a game
- Game the system
- Games that work
- Turn on your brain
- Work meets play
- Smart play
- Intelligent play
- Play smart; work smarter
- bFun. bSmart.
Sunday, 15 February 2009
- You have to be the most passionate person involved.
- Get off the computer - the act of writing things down on paper frees the mind, allows for the juices to really flow.
- Obsess about the details, down to the space between two letters.
- Do your own support. You have to be able to feel the pain of your users. Document everything. Make it as easy as possible for your users to contact you.
- Blog every step of the way. Keep all of your users in the loop at all times - they will love you. Communicate with them and put them in the driver's seat.
- Have a great tagline. If you can't describe what you are doing in less than 5 words, edit it, shave it down.
- Frame everything you're talking about in a context for your users. What are you going to do for them?
- Get out of version 1.0 as fast as possible. Most people make their successes on something different from where they started. Be flexible. User feedback is the most valuable asset. Don't let yourself be too led by your first users. Listen to the silent majority. Keep the majority in mind.
- Track yourself.
- Know what to do if you are successful.
- Start strong, end strong. People don't often remember what was in the middle.
- Be a pain killer, not a vitamin.
Excellent food for thought. One that caught my eye was #6. The problem: Get the shiny draft mission statement down to a snappy under-five-words tag-line.
Tuesday, 10 February 2009
Unfortunately, many have not been so lucky. Over one-hundred-and-eighty people are confirmed dead with estimates that this will rise to over 300.
Today I was saddened and shaken by the news that a family that I know -- a mum, a dad and two children (only a few years older then my own) -- perished while defending their home.
What to do?
Like most Victorians we are donating money, in our case through the Red Cross Bushfire Appeal. In addition Andi is donating patchwork quilts to the destitute. We are looking into other ways that we can help.
I urge all Australians -- especially Victorians -- to donate generously, and if possible to also help by donating goods, personally volunteering, and offering shelter to those rendered homeless.
Monday, 9 February 2009
"I had to wrestle one boy, to stop him from being mean to another child."Further questioning failed to yield meaningful elaboration. In the absence of calls from the school I guess we'll just have to assume (hope?) that Jake was on the side of the angels.
So to any bullies reading this, remember: "Don't mess with red".
Wednesday, 28 January 2009
"What do you do in your spare time?"since it tells you a lot about what the candidate is passionate about.
Now, I have been asking this sort of question in social settings because I am not a great smalltalker -- although I'd like to learn one day ;-) -- and usually asking that question (or what's your passion or hobby) get's people engaged and open up. Unfortunately some people are very obsessional and will launch into long monologues at the sniff of such an invitation, in which case it's time for me to interrupt, excuse myself and go and get another drink (especially in this heat).
Anyway, while I think it's an interesting question, I am not sure that it is that easy to interpret the answers. I would suggest supplementing it with a follow-up when there is no obvious connection:
"What have you learned from full contact macrame [or whatever] that relates to your day-job?"Let the interviewee do the hard work!
But often the conspiracy theory is much funnier, and just rings truer. Witness this spoof interview with Bjarne Stroustrup, creator of the C++ programming language. Snippet :
Bjarne: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers?Gold.
Tuesday, 20 January 2009
Solutions Selling is a codification of smart sales practices by Mike Bosworth dating back to 1983. Originally Bosworth went straight from College to pursue a career in the technical support at Xerox corp., before it was suggested that he try his hand at sales, which he did (at first reluctantly). The book was published in 1995.
A Consultative Approach
Rather than foist your product on an unwilling (or even willing) prospect the Solutions Selling approach encourages you take the buyer's perspective and work with him or her in a non-pitchy way. By the end of the process a decision to buy should be a "no-brainer":
- the customer should feel ownership of the resulting solution
- the value should be evident to the customer how the purchase leads to enhanced capabilities
- these enhancements should be quantifiable, so that the purchase price is justified to other people in the customer's organization
- the customer should feel personally empowered by the experience and the result
- the personal relationship with the salesperson should be perceived as positive
Solution selling lends itself particularly well to large complex offerings. For example
- Service and product combination
- When you compete on customization and/or integration
Let's divide prospective customers into groups / stages:
- Not in target market: No need for your offering(s).
- Latent need: Not aware of a need that could be satisfied by purchase
- In pain: Aware of the need ("in pain"), but unaware of how your offering can help
- Vision creation: The prospect has a vision or a "Solution", ideally including your offering
- If the prospect is in group 1, go after someone else rather than try to sell them something they simply don't need. Better to steer them in the right direction and build trust and respect for the longer term.
- If the prospect is in group two, use appropriate questioning to get more clarity, but also to move the prospect toward a clear perception that they have a real need (which would move them into group 3)
- Quantify the pain, find out who else in the client organization is affected (and go talk to them), find out who has the power to buy, find out which hypothetical capabilities would enable them to address their pain
- Two possibilities: They are already heavily leaning towards a competing vendor's vision / offering (you need to realize this, and use FUD to un-sell them and get them to come over to your vision -- "re-engineering"), or use what was learned previously to put forward a jointly-developed vision that they know will give them real, quantifiable value.
The actual Solutions Selling methodology explicitly fleshes out how to do it!
It includes lots of advice and tools including a detailed and distinctive nine-block vision processing model.
Challenges in putting it into practice
Naturally, Solutions Selling is not a panacea (silver-bullet):
In a freely available McKinsey & Co. report (registration required), Solutions Selling: Is the pain worth the gain?, the following points are made:
Unfortunately, our discussions with over 60 solutions sellers suggest that three out of four companies selling solutions fail to see sustainable economic impact.They suggest that some possible keys to getting Solutions Selling to work well (my emphasis):
First, you have to understand how a solution is positioned in terms of two key variables, customization and integration. This positioning drives the basis of your competitive advantage and - most crucially -the "pain/gain" trade-offs you need to understand.Comment: The essential dimensions, one and two, on my reading amount simply to properly applying certain parts of Solutions Selling properly (as distinct, I suppose, from paying lip-service).
Then, you have to execute quite differently from a standard product-based go-to-market model in at least the first two - and preferably all - of five key dimensions:
Solutions selling is not for everyone. But for those who understand and can implement these imperatives, there is tremendous upside.
- Create distinctive solutions value propositions using customer business metrics, not product price/performance metrics.
- Radically change the selling approach, and if necessary, the sales talent.
- Price solutions based on total business value delivered, not component features.
- Align the entire organization, not just sales, with the solutions opportunity.
- Maintain control of all aspects of implementation to ensure end-to-end value delivery.
However, this may not always be simple. The report suggests that on average 2/3 of salespeople with a background in product-centered sales are unable to successfully make the shift to Solutions Selling. They recommend that "stars" be recruited from other areas, suggesting that star-sellers are either:
- Already doing things similar to Solutions Selling (so the shift is smaller),
- Are more adaptable than regular salespeople in terms of trying a different approach, or
- Will be successful independent of the methodological approach adopted by the sales-team!
Solutions Selling is a consultative sales methodology that reminds me a bit of the Getting to Yes school of negotiation in that it aims to move away from negative relations between the two parties (e.g. adversarial, distrust, fear) towards cooperative problem-solving to seek out win-wins.
It has repercussions for the individual salesperson in that it encourages a specific systematic approach, but promises improvements in:
- efficiently deciding which opportunities to pursue
- improved client engagement
- better professional relationships and reputation
- Suitable organizational alignment with suitable offerings and pricing
- Sales and other staff to execute on the approach (or at least most of it)
- Technological support (tools that make the tasks easier, help apply essential parts of the methodology appropriately)
The more things change, the more they stay the same.
VisiCalc was a product, not a program. Decisions were made with the product in mind and, to the extent possible the programming was towards this end. In practice it was more complicated as we were designing against the limitations of the personal computers, price point and, most important, what the user could understand.
The goal was to give the user a conceptual model which was unsurprising -- it was called the principle of least surprise. We were illusionists synthesizing an experience. Our model was the spreadsheet -- a simple paper grid that would be laid out on a table. The paper grid provided an organizing metaphor for a working with series of numbers. While the spreadsheet is organized we also had the back-of-envelope model which treated any surface as a scratch pad for working out ideas. Since we were used to working with powerful computers without worry about the clock running, we already had the experience of focusing on the users needs rather than the computers needs.
The ability for Dan and I to work as a team was crucial. While he could've written the program, the fact that he wasn't gave him the freedom to focus on what the program should do rather than how to do it. I could appreciate his reasons and would eventually accept that I had to change code that I had labored over. We were able to find ways to take advantage of the limited space available for the program in deciding what features to include or not include.
The original version put the entry area at the bottom of the screen. By playing with this simple prototype Dan found that it was better to put the entry area at the top of the screen and I made the change to the evolving program.
In addition to prototyping, Dan put together a reference card for users. If we couldn't figure out how to explain a feature on the reference card we would change the program. The original method for copying formulas was too complicated so we just changed the design rather than try to explain it.
Wednesday, 14 January 2009
- Don't take away a train when someone's playing with it.
- Don't rip the Thomas and Mr Men and Little Miss books.
- Don't break up the track.
- Don't interrupt a story.
- Be gentle with the lego.
- Don't rust the trains, and don't scratch people.
- Don't jump on the bed.
- Be careful when you wind up the sling bridge; it might break.
- Don't come in when I have privacy.
- I like tickling, and stop when I want you to stop.
- Don't jump on the bed, pillow and doona.
- Don't interrupt my books and don't break my boxes.
- I like tickling, but stop when I have had enough.
- Mummy and Daddy are the bosses of the house.
- No biting, slapping, or hitting.
- When you finish your food, bring your plate to the kitchen bench.
- Use an inside voice.
- No TV on school mornings.
- Children must brush teeth and get into pyjamas before getting "bedtime choices".
- All family members must support the Collingwood Football club, or leave home.
- You get what you get, and you don't get upset.
- Remember to put out the bins on Thursday nights.
- Full participation is expected during Shabbat blessings, and this includes guests.
- Don't waste water; the farmers need it.
- A quick game's a good game.
- The house must be tidy before the cleaner comes to clean.
- Obsessions, such as martial arts, patchwork quilting, trains and fairies are to be tolerated, nay, respected.
- Tickle the mickle is the preferred format for tickling.
Monday, 12 January 2009
The table-of-contents post appears on the left, with chapter headings and links, but the neat "feature" is the table-of-contents that appears on the top-right of my blog, making it easy for me to navigate, and for readers to get an overview and dive in to whatever interests them.
Already I have had some positive feedback about this feature, and I would encourage others to emulate it for the sake of their readers. It seems to make a nice complement to tags, which are a bit more like an index, and archives, which tell you what's new.
The set-up steps in Blogger (it should be similar for other platforms) are:
- Invent chapter headings for your blog
- Create the table-of-contents blog entry: E.g. myblog.blogspot.com/toc.html, or (nowadays) a page and include your chapter headings.
- Tag every heading with using Edit HTML in the blogger editor by wrapping it in anchor tags: e.g.
- Go through all your old posts and put links to the better ones under the appropriate chapters.
- Make a text widget that points to your table-of-contents entry and the chapter headings. The hyperlinks from the chapter-headings take the form
- Place the text widget somewhere prominent.
- Each time you add a new post that fits your theme, add a link in your table-of-contents post.
- Occasionally you may want to add a new "chapter", which involves editing the widget as well, but this should be a fairly rare event once you have your categories straight.