Clever Hamster

Ode to FAQ

Technical writers tend to take a dim view of FAQs, those "Frequently Asked Questions" that, in fact, aren't questions. Much criticism of them falls into these categories:

• Hoarding. You couldn't figure out where to stuff this random bit of information, so it goes into the FAQ, just to be safe.
• Dishonesty. You want to feed them marketing information without seeming to do so, with disingenuous questions no user would ask: "What are the major features of ProductX?"
• Laziness. Gotta close this Jira by posting some kind of update to the docs, and just adding it to the FAQ (without rewriting the old topics) gets 'er done.

Yes, yes. And yet, I promise you that when I tackle a new product or platform, I often run first to the FAQ for a deliberate scan, especially if they're written by Support (who might publish them as solution articles).

But why? because FAQs often reveal what docs rarely do: friction.

We tend to write documentation starting with the Happy Path, the actions and sequence that yield success for the ideal use case. That's useful for quick orientation to what the product feature has to offer, but it's far from enabling. The iterative growth of the documentation should walk users through their use cases, as we discover more what they are, as we all learn more. We should craft the words and examples in a way that sets their expectations for what the product can and can't do for them, and what to try instead.

So: where docs are founded on Happy Path, the best FAQs are founded on pain. User pain. The good FAQs delve into the gritty and sticky parts of the product, where users get lost, mislead, and stuck. Done well, they reveal not only the bad news, such as an integration that isn't possible, but also the reason why and how I might approach the problem differently. They point to where the UI tends to confuse and frustrate. They reveal the chalk outline of missing functionality.

The reason I run to the FAQ with a new product is that I want to kick the tires and see what flies out of the wheel well. I'm perfectly capable of figuring out the happy path, but that's not enough. I want a peek into the limitations I may hit. I want to see where others have stalled out, with what use cases (which might affect mine). I want to hear workarounds, which reveal worlds about how things are actually working. I want to learn where others struggled, so I can choose another path. I want to jump into the messy stuff to grow my confidence that I can navigate around the pitfalls.

If I'm going to make a commitment to this product, I need the authentic stuff.

In the end, documentation should only exist to empower users. If a FAQ is written with that in mind, it's gold.

Syncing Google Docs to WordPress

As promised, here is part 3 of my post about publishing using Google Docs; this one deals with how to keep already-published WordPress articles synchronized with source content that lives in Google Docs. 

GoPublish is the missing piece for syncing from Drive. It’s a newly expanded Google Suite/Workplace application that connects to your WordPress instance so that you can publish new or updated articles (any type) right in place. 

It's a game-changer for sourcing your WordPress content safely in Google Drive.

Why Sync?

Here’s your TL;DR for the first article:

• Google Docs is an easy, cost-effective place to collaboratively author source files for documentation
• WordPress is an easy, cost-effective place to publish docs, via knowledge base plugins
• Some way is needed to keep gDocs source synced up with WordPress articles

Not far enough — It’s true, there already exist several tools and integrations that push content into WordPress, such as for blog articles. However, their focus is largely on “touch-once” publishing, exporting Google Docs and formatting it for quick, one-time insertion into a steady stream of new WordPress posts. For Documentation and Support sites, however, writing is cumulative and iterative: writers need a way to push docs out to WP and then, later, push updates out to those generated pages, without loss to their URLs, names, categories, or tags.

GoPublish started as a “push once” tool, but it has been expanded to encompass full synchronization. It lets you publish new WP content into any custom post type and publish subsequent updates right in place, all without going to WordPress. 

How it Works

The GoPublish app is an extension you install into your Google Docs account, and you manage your syncs via the extension side dock (right side panel), without leaving your document. It handles publishing for the currently open document: it connects one Google Doc to a post in one of your defined WordPress instances — one document linked to one article. It’s not a bulk processor; when you rewrite a Google Doc and it’s approved for publishing, you publish that one document.

Licensing: There are several subscription levels based on the volume (how many exports a month) and the level of support you need. Access is granted to the Google account you used to sign up. For best results, don’t connect multiple Google accounts in the same browser: that can cause problems with many Google applications.

Updating Custom Posts

Because the most revolutionary use case that GoPublish supports is updating existing custom post types, I’ll walk you through this path:

0 - Connect Domain — The first time only, you will need to connect to one or more WordPress domains, which you will select from for future publishing. GoPublish always has to connect to the domain first in order to detect its custom post types and taxonomy.

1 - Choose Export Type — From here on, the first step of each export is to select the type of publishing you want, because different export options need different options:

• Export Post — These are standard WP blog posts, with categories and tags.
• Export Page — These are standard static pages, which don’t have categories or tags.
• Custom Post (Export or Update) — This is the amazingly flexible feature, the ability to publish content into any custom type. Your documentation or knowledge base plugin will have its own custom post type, which you’ll select from the custom types found in your WordPress instance. And you could single-source even broader types of content, such as the lessons for your WordPress LMS (we use LearnDash).

2 - Select Domain — Now the export begins: Select the domain to publish into (this can include your staging and dev sites). Once connected, it will prompt you with values specific to that site.

3 - Select the Post Type — Next, select which custom post type to update. The more plugins you run on your site, the more custom post types may appear here, such as the ones below that begin “sfwd-”, which are for LearnDash. For example, my Echo Knowledge Base custom type appears here as epkb_post_type, and, because it supports multiple knowledge bases, each one has its own number: epkb_post_type_3. When I publish into my documentation site, which is the third knowledge base I created, I choose the third one:

3 - Select the Post ID — Next, enter the ID (or URL) of the post you want to overwrite. (Tip: Post IDs appear in the URL when you edit a post.) Click Verify post, and look for the green checkmark. The Title field populates from the existing title for the WordPress post, which you can override manually or select the checkbox to use the Heading 1 from your Google Doc.

4 - Set Image Export — You can have the sync push copies of the images into your WP media library, but using the library is not recommended for high numbers of images, both for WP performance and for the time it will take to transfer all of those files into WordPress. The superior and breakthrough option is to let the sync export the images to GoPublish’s third-party CDN (content delivery network), which optimizes cost-effectiveness and performance. (GoPublish also includes a separate Image Size Checker, so you can scope the number, size, and type of images in your document.)

4 - Enable Other Settings — Finally, there are settings to configure the WordPress article as you need, such as opening links in a new tab, making links “nofollow” (to prevent spam and protect privacy), and exporting YouTube links as embedded players. I strongly recommend you enable the last two: 

• Include image alt-text from alt text input (To add this in Google Docs, right-click an image, select Alt Text, and complete the Description.)
• Add Google Doc link as markdown comment
  
  

That last one is a terrific feature: whoever edits the post will see a markdown block with key information: the URL of the Google Document that is the source file and the date of the last update. This ties them together: to jump back to the source file, highlight the URL, right-click and select Go to…

5 - Update Post — Select Update Post and go! How long it takes to update very much depends on the speed of your site, the length of the post, and the number of images to process. Offloading the CDN is faster than writing to the WP Media Library, but it still takes time. After you see the success message, you’ll have two helpful additions:

• The link to your post is added below Export Links.
• The ID of the synced post is added to the end of your Google Doc name, so you know it's been synched and you have the ID handy to update next time.

Why it Matters

Much like how generative AI is changing how we work and what we believe is even possible, Google Docs has been that for organizations and institutions. By having a publishing bridge between Google Docs and the world’s largest website platform, we bring the work of technical publishing into the daily toolset that everyone is already using. Where we all work together, we can collaborate without friction and cross the silos so common in our shops. 

And it’s the small app developers, like GoPublish, that have the agility to bring new tools into reality in mere weeks, not years. Job well done!

Merge Google Docs into User Guides

As promised, here is part 2 of my post about publishing using Google Docs; this one deals with how to merge docs into books and deliverables.

Document Merge for Google Docs™ is a new Google Suite/Workplace application that allows you to merge sets of Google Drive documents into one output. The app is an extension you install into Google Sheets (not Google Docs), and you configure and generate your book building from the sheet that manages each publication project. It's a game-changer for authoring in Google Drive.

Why merge?

Content as Components — Google Docs (at the time of this writing) has no way to insert, combine, or embed child docs into parent docs, such as Microsoft Word's Master Docs (or sturdier RD field codes) allow. This limitation has blocked professionals from considering Google Docs up to the task for larger projects: 

• Technical documentation: Rendering user guides by ordering/reusing individual topics 
• Reference guides: Rendering a dynamic folder of articles into a printable unit
• Book authoring: Rendering a complete book file by assembling individual chapters and appendices

In all of these cases, individual component documents need to be mapped as the building blocks of larger deliverables. 

Reapplying Templates — Another serious limitation of Google Docs is its lack of template control. While there is now rudimentary ability to update, store, and reapply paragraph styles to documents, authors cannot keep documents locked to an official template (page layout, headers/footers, styles) that changes according to branding and submission needs. When such updates are needed, authors face a miserable slog of updating each component document by hand.

Document Merge for Google Docs removes both of these blockers: with the Pro version, you can combine static and dynamic sets of documents into one deliverable, and you can base it on a shared template, so that each regeneration of the merged document is using the latest template.

BYO Format — Document Merge for Google Docs goes one step further in embracing more use cases by being document-type agnostic: you're not stuck working with Google Docs as source files. You can merge many types of source files stored in your Drive: 

• Native Google Docs
• HTML file
• Text file
• Microsoft Word DOCX file
• RTF file

By embracing these other document formats, the app opens the door to working with content exported out of other tools and platforms. You can mix and match source material into unified deliverables, which used to require large investments in server-based tooling. Once merged into a Google Doc, you can export it back into these and other formats (such as PDF) as needed.

Advanced features

Subscribing to the app changes the feature set. The number of files merged are subject to Google's quota limits and depend on the version you are running:

• Free version — Each merge combines the first 5 source documents in your sheet.
• Pro version — Each merge combines up to 200 documents in your sheet. 

The Pro version adds extensive features:

• Specify the URL for source folders, which it will process recursively, such as to capture an ever-changing folder of troubleshooting articles into a reference guide.
• Start each subdocument with a page break.
• Control your output:
• What document Title to use
• Which folder to save into
• Whether to use a Google doc as a template (headers/footers, copyright, TOC)
• Whether to merge into an existing Google Doc, and whether to empty it first
• Whether to apply these settings to just this or to all project spreadsheets

Project setup 

To get going with this app, first install and set up the sheet.

1. In a new Google Sheet, select Extensions > Add-ons > Get add-ons, and search for "Document Merge for Google Docs" (be careful not to select ones for mail merge).
2. Install it, then select Extensions > Document Merge for Google Docs > Merge Google Docs.
3. Select the Setup Spreadsheet button, which adds the required sheets and columns.

The app prepares two tabs (sheets) for you, the first of which you need to populate for your project.

(1) ActiveList — Describe and link each item to combine in the output:

• INCLUDE — On each row, set Yes to include this item or No to skip it in the next merge
• Description — Identify the URL to the right; this does not appear in outputs
• URL — Add the Google Drive URL of the document, file, or folder (Pro)
  
  
  

(2) Results — After you merge, use the Results tab to see and access all of the merged docs, from oldest to newest:

• NewFile — The name of the new Google Doc that was created
• GoogleDocUrl — The URL of the new Google Doc, which defaults to your My Drive folder.
  
  

Output customization

Output Details (Customize) - In the Merge Documents sidebar, select the Customize link to change your output details (Pro only).

• System Default — With the Free version, you are limited to these default output settings:
• Name — The merged Google Doc is titled "MergeGoogleDocs + Date"
• Folder — The merged Google Doc saves to your "My Drive" folder
• Setup for this Spreadsheet —  Use this option to customize this project only.
• Setup for All Your Spreadsheets (That use this setting) — Use this option to globalize your settings to all spreadsheets that you open with this Google Account. 

Output To New Google Doc — Use this option to build a new merged document from scratch:

• Name — Specify a name for the new document, or else the default naming will apply.
• Output Folder — Specify the URL for the folder on your "My Drive" where the new document will be created. If the URL is valid, you'll see its name appear with a link.
• Google Doc Template URL —  Specify the URL for the Google Doc to use as a template, for page setup, front matter, header/footers, and table of contents. If the URL is valid, you'll see its name appear with a link.
  
  

Output To Existing Google Doc —  Use this option to send your newly merged document into an existing Google Doc on your "My Drive", so that its URL and page history stays intact.

• Specify Google Doc URL —  Specify the destination document. If the URL is valid, you'll see its name appear with a link.
• Delete Existing Content — Specify whether to delete the existing content before inserting the new (otherwise, the new content is appended to the old content).

Troubleshooting

Here are some tips to help things go smoothly:

• Always check the URL validation. When any URL you entered is valid, the app displays the name of the document or folder under the field, with a link you can verify. A common reason validation fails is access permissions, such as creating outputs on a separate Shared Drive, which isn't supported currently.
• If you get system defaults, look for errors. If there's a problem with your setup, the app will fall back to defaults in these ways:
• If the document name is missing, the app will use the System Default naming.
• If the output folder URL is empty or invalid, the app will create it in the same folder as the Template, if you specified one (if not, it will fall back to your "My Drive" folder).
• If the Template URL is empty or invalid, the app will create the document without one.
• Reach out. If you need help or a dedicated solution for your team, contact Support directly: [email protected].

Cloud Publishing for Docs: Google Docs to WordPress

We technical writers love shiny, elegant tools to forge our craft, but serving our startups is about supporting what they need right now in a way that is easy for them to maintain, adapt, and afford. To that end, I want to describe a brand new cloud-based tooling chain for documentation that I helped give birth to this past month: Google Docs to WordPress.

I hear you sighing “But why these? Ew!”, so I offer you a steaming cup of practicality: 

Google Everywhere — In my experience, younger startups standardize on Google Docs, and the interns all come from schools and colleges that use Google Docs. This landscape of common use brings tremendous benefits:

• Collaborative cloud authoring: Users expect to share commenting, writing, and editing with their teams
• Org-level access: Google Suite is not licensed like Confluence, so there’s no running out of or managing seats, or being unable to afford the subscription for needed extensions
• Document management: Users gain comfort with standard skills: create, search, share, move, copy, embed, export
• Version control: Users view version history, compare versions, and restore prior versions
• Controlled styling: Because users cannot create new styles, docs do not explode with styles (as Word does)
• Expanding capability: Style features Page Break Before and Keep With Next snuck in, and more keep coming
• Friction-free: No battling users to give up their comfortable writing environment for the sake of “the docs”

That last one is key for project success: bring the tools to where your coworkers already work each day, and you’re halfway there.

WordPress Everywhere — Groan if you will, but WordPress is still the most popular CMS in the world, running over 43% of all websites and 64% of those using a CMS (Google Bard tells me). Why? Largely because it is free, open-source, and highly extensible, with thousands of very affordable plugins and themes. The barrier to entry for businesses is nil, and finding freelancers to help build it out is as easy as it gets. However, it is not, itself, a good platform for authoring technical documentation. These limitations are deal-killers:

• Not collaborative. WP is an environment for posting content, not developing it with a team before publishing.
• Unintuitive. Our coworkers are comfortable writing in Google Docs but would never touch WP by choice and would rebel at the sight of the Gutenberg Blocks interface.
• No version control. Best practice is to disable native WP versioning for performance reasons. My WP dev assured me most shops rely on Google Docs to keep their source.
• Requires a CDN. Again for performance (and cost), media needs to be offloaded to a CDN, which worsens the complexity for casual authoring.

True confession: It wasn’t feature analysis that brought me to WordPress; it was pure expedience. My shop already had enterprise hosting and its marketing presence in WordPress, and the new online learning initiative was going to extend that platform, making use of low-cost LMS plugins to WP. As I’d be on the hook to maintain content in WP to support those self-paced courses anyway, why not migrate the product documentation there as well, and reuse the same user accounts? That reuse of accounts would be much better for customers than our alternative. Equally important, I faced a formidable Help constraint: I needed a way to push content into Elevio, our existing in-app Help module, and it had an integration plugin for WordPress – and free, at that. The integration I had tried via Confluence through Freshdesk (our prior tool) to Elevio proved far too heavy and expensive.

So … it looked like I would use Google Docs with WordPress, but I faced a tooling disconnect between authoring and publishing. Now what?

Building a Tool Chain — So much searching, but I found no tools that connected the cloud publishing chain I needed, or at least without great effort and expense. Here are the two critical connections I most needed:

• Help Topics — How do I publish and maintain articles in WordPress, keeping the living source in Google Docs?
• Guides — How do I generate branded user guides by combining Google Docs source files?

The breakthrough came from my reaching out to Google Marketplace app developers about what I needed, about how to extend their new tools to my use cases. In both cases, these tools might solve my problems, if only several key features were added. Lucky for me, both developers were interested in reaching a larger market audience of technical writers.

These are the two Marketplace apps that I'm in final testing with, one extending Google Docs, and the other, Google Sheets:

• GoPublish — Connect to one of your WordPress instances, to push out new WP content (any post type) or update it in place.
• Merge Google Docs — Map and generate publishing outputs from a list of Google Docs and a Google Doc template.

This is where these Google Marketplace apps (in yellow) fit into my publishing chain:

In parts 2 and 3 of this blog, I’ll detail the documentation-friendly features of these tools.

Writing Great Error Messages

These resources for authoring error messages were just shared on the Write the Docs Slack community, by Monique Semp; they were too good not to save! (On the free plan, our WTD content goes away after a time.)

If you're not on the Slack community, get on over: writethedocs.org/slack 

• Error Messages: Examples, Best Practices & Common Mistakes
• Are there any industry-standard best practice guidelines available?
• User Interface Text: is it OK, Now?
• Message Text - moremiscellany
• Messages (Windows)
• How to Write Error Messages: Faster, Stronger, Better - Technical Writing Tips
• The art of the error message – The Style of Elements
• How to write better error messages
• The 4 H's of Writing Error Messages
• How to Write Error Messages
• Error Message Guidelines (Nielsen Norman Group)

How asynchronous meetings speed Agile

As my company was just acquired, I'm turning my attention to our organically developed Agile processes and noticing how it is that we stay so Agile and almost meeting-free. This just happened this morning:

While I was busy on a call, a lead developer needed some decisions finalized so that he could finish the UI for a new feature. Discussion in the Jira ticket had been progressing too slowly for him, so he started a Slack conversation with the product manager and with me, because the technical writer gets pulled into anything involving customer-facing language choices. 

 

In Slack, we hashed out the problems and questions, did some quick mockups, reworded the screen text, and thought through the implications for users. In only 15 minutes, development was unblocked, new language was approved, and I obtained key details I that I would be needing to make the documentation useful. 

 

Here are key benefits I spotted in this method:

• Immediate — My dev lead didn't have to wait for the rest of us to be free for a meeting or wait for a standup to say that he was blocked.
• Multitasking-friendly — The asynchronous nature meant that we were efficiently answering other Slack channels while we waited for each other to think and write up responses.
• Documented — Unlike meetings, it leaves a complete written trail that we can search later for the details. We do record our Zoom meetings, but those are opaque to text searches.

I'm pasting the important bits of the Slack conversation into the Jira ticket so that we don't lose the history of what we decided and why. Our goal is always to make the ticket the repository of historical truth, so that a new person coming along later could reasonably catch up on the who, what, where, when, and why of the issue's life and jump in right from there.

How we came to this technique is, I think, a natural development of our being remote and distributed across time zones. To use everyone's time well, most synchronous meetings simply had to die. 

And that's a good thing. :-)

Don't get me wrong: it's lovely to see team mates; it's just that synchronous meetings aren't the way to get the most done. They are ephemeral, they bog down across time zones, and they don't scale. The efficient way is to use our messaging platforms for asynchronous meetings

Growing tech pubs on top of Confluence, like Salesforce.org

Atlassian's abandonment of technical publication and help authoring as a key use case for Confluence is nothing new: 5 years ago they admitted it (CONFCLOUD-2522), and it explains our excruciating experience of being pushed onto a new Cloud editor that lacked critical functionality (50+ issues being tracked) that we rely on to author and produce our documentation.

Suppose that the economics of their market strategy are sound, and we're just not worth the development burden. What then? especially as our shops keep tight to the Atlassian stack?

Atlassian is becoming an enterprise platform that, in its broadening focus, needs considerable configuration with add-ons to fit any given organization -- much like Salesforce. And that comparison may suggest a path for us.

In 2008, the nonprofit community trying to use Salesforce started working together on the first version of NPSP, the Nonprofit Starter Pack, an open-source project to build out essential CRM functionality that most nonprofits need. It handles technical support via community-based forums and knowledge bases called Power of Us. All NPSP custom applications sit on top of the core Salesforce platform and evolve with it, all while being quite distinct from Salesforce's core mission of commercial B2B sales. Its separation from Salesforce is, I think, key to its unique success.

So, if technical publication is too niche a sector for Atlassian, yet we technical writers have a well-known set of common needs, could we not start a community to make this platform work for us? Could we have our own bundle of integrated add-ons that cover our needs for document control, version control, export design and automation, and more?

Confluence has always had add-on vendors who each cover portions of the tech pubs use case; premiere among them has been K15t. But the nature of Atlassian licensing has meant that the cost of assembling a huge collection of these needed add-ons is cost-prohibitive in most shops, end of story. It will never be the case that specialty tech pubs add-ons would or should be in the hands of most members of the organization, so pricing just never makes sense. My Support folks writing kbase articles use none of the power features that I do.

But what if we approached this as a community? What if we could license the bundle as a community member? What if the community entity licensed Data Center and enabled all the tech pubs add-ons, and we community members could pay for just the spaces and usage we incur from that shared whole? What if interested organizations could sponsor development on the add-ons and automation they most need, such as for translation control or exporting to LaTex? What if vendors such as K15t worked directly with the formal community of tech pubs users, which operated its own community-based forums and resources?

What if we each didn't have to go it alone?

Why "Clever Hamster"?

Well, a family joke: Whenever one of our hamsters (and we had several hamsters over the lean years of graduate school) found a particularly huge treasure (rotten potato slice, yard of yarn, birdseed bell), she would carve it up and hide it away in her nest with amazing enthusiasm and passion. Watching this, we'd tap our foreheads, look sly, and say "Clever Hamster!" After that, whenever one of us would have a bright idea, we'd do the same forehead-tap and "Clever Hamster!" cheer.

That's it. That's the story. (blush)

Road to Cohousing: People over Things

On the road to a future in cohousing, I have been on a dizzying journey: just this month, I moved to an in-town condo, and in so doing I have literally shed over half of my square footage and three-quarters of my family's accumulated material. Not that downsizing is so unusual: cross-country job hunters, house-poor retirees, the newly divorced, medical crisis survivors, and seniors face these kind of downsizing projects in great numbers, so often under duress. What may make me unusual is having embraced this pain before it was necessary. The upside? It feels better to go through the ordeal with some sense of personal choice, purpose, and control.

Why is downsizing so brutally hard? Beyond the immense physical drain of the effort, downsizing has crushing emotional and spiritual heaviness if it lacks empowering framing. Unless downsizing is the door to your vital future, it will be experienced as an agonizing series of losses (that was the kids' favorite TV chair; that huge Christmas tree was my dream). This is why we should be compassionate with our elders who fight relocation with what looks like irrational ferocity. "But I need you to be safe" rings hollow if it seems to come at the cost of everything she knows, relies on, and treasures, her comforts and very identity. The only way to reach peace is for her to see a vital future worth the change.

How I found my vital future, I realize now, was to define it in terms of cohousing, of moving into intentional, supportive community. I came to see that all-eggs-in-one-basket dependence on the nuclear family for emotional well-being perhaps works for some folks at some times, but it seems a poor strategy for the post-empty-nest phase of life, where households shrink and change and employment wanes. Space opens up in this phase of life, but our old suburban environment (which has ample busywork in the form of constant upkeep) lacks an organic means to infuse daily life with revitalizing and nurturing activity. Like a butterfly, we need to dissolve and rebuild ourselves to master what's next. Downsizing is our chrysalis.

Cohousing — short-hand for living in intentional community and sharing common spaces — has, at its core, the secret to downsizing: placing people ahead of things.

Things. During the nesting and chick-raising years, we become intensely thing-focused: rooms for kids; yards for pets; cars for errands; patio for parties; storage for decorations; upgrades for property value. Tremendous focus, time, and treasure goes into crafting our living space and all of its comforts and entertainments, all toward an imagined future in which we'll slow down enough to actually enjoy them. What we miss in that is the understanding that it comes down to Enjoy them with who, right now? Waiting around for grown children to visit relegates the bulk of life to gray in-between time, for many of us. And home improvement and maintenance, which we once met with ambition, now is left a tiring ritual detached from its prior urgency. Many punctuate these days with travel, but that can be largely a mechanism to flee the gray and fill the time. This heaviness is not a sign of a problem but of it being time to change. 

People. Cohousing is designed to encourage deepening of the community that calls it home. Like a retreat center, most cohousing prioritizes a central common space for people, to serve the needs of the group: a commercial kitchen, expansive dining/meeting room large enough for all, shared laundry and workshop/toolshed, yoga/exercise facility, guest rooms/suites, living/library room, art/craft space, community garden, car-sharing, and shared greens/playgrounds. The design encourages members to naturally spend ample time together in the community space and shared meals, so that private apartments can be smaller and simpler. Higher density is not only more cost-effective, but it facilitates easy interaction and connection, which is the heart of our vital future.

In the end, all of the things we worked so hard to buy were ultimately to be about enjoying ourselves with others we care for. When we firmly put people ahead of things (as I remember Suze Orman teaching in her financial training), we begin to correct our course. We see how our choices have become constrained by the needs of our stuff (cue George Carlin here), which is really backwards. We see how chasing security made us put our trust in things and neglect interdependence and community.

The problem is not finding practical help with downsizing strategy (you've doubtless heard of the delightful Marie Kondo and the book The Gentle Art of Swedish Death Cleaning, for example); the problem, I think, is deeper: how to want to downsize. That's where the vital future comes in: when we see living differently, living in community, as the longing of our future self, we can understand excessive things as being the barrier to that journey. We want to release whatever doesn't support us getting to that new home, which won't have space to house the museum of everything we've used and loved. Like the monkey who is stuck with an arm in the vase because he refuses to let go of any of the things he's grasping in his paw, we have to see that letting go of objects is the very means by which we can break free and get to a better place. 

And it is a better place. My new condo community has lots of retirees and single women like me, and every dog walk or trip to the mail can be an hour of happy greeting and getting acquainted. Just by eating my sandwich in the courtyard by the pool, I am easily approached by neighbors hoping to meet me or share some advice. There is comfort and belonging in this condo of a 100 households, where I already know more people than I ever did in the suburbs; how much richer and deeper will it be when there are only 20, and we share so much more?

ATX Aging & Innovation Summit

The ATX Aging & Innovation Summit sold out again, but I'd gotten my ticket in time. This year's focus was "Aging in Community", which aligned perfectly with my interest in innovation in housing, especially cohousing and cooperatives. Highlights for me:

Design Thinking — A team of IBM facilitators gave us a hands-on workshop, training us how to use IBM's Design Thinking process to research and brainstorm solutions to hard problems: ignorance of services, isolation from community, and generational segregation.

Tech Startups — Mary Anne Connolly of MACMedia ran us through a panel of CEOs describing their startups:

• Iris Plans offers a free service (paid by insurance companies) to guide seniors and the chronically ill through their health directives, using video conference calling with an expert to facilitate the family discussion with adult children.
• Clairvoyant Networks is harnessing the IoT to support caregivers of memory patients: combining wearables with other sensors communicating over locked down wireless service, caregivers can remotely evaluate conditions, track location, and be reached in a button press.
• Theora Care and CareStarter couldn't make it, but Guide Change, part of the Capitol Factory incubator, crunches data to spot potential financial mismanagement and even fraud from relatives, problems most commonly affecting older widows.
• Remedy, already established for urgent care house calls (with compact testing labs), is now branching out into video-based telemedicine that progresses to house calls only as needed. The primary focus is keeping Medicare patients out of the ER, but the model is growing for providing primary health care via organization-specific portals. Unlike other telemedicine approaches, they don't lose patients over "what if I need tests?" worries.

Google Accessibility — The closing keynote was a sweeping overview of accessibility technologies and challenges, given by Henri Fontana, who is Technical Program Manager of Accessibility at Google. A version of this talk will be given at SXSW Interactive next year. I came with a solid background in accessibility requirements for software products, but this session was far broader and focused helpfully on a fuller range of disabilities and specifically on the issues associated with aging. For example, the more subtle cognitive issues that worsen with age include lessening ability to sustain concentration and lowering tolerance for cognitive load (multi-tasking), leading to frustration (easily overwhelmed and defeated).

Given that aging users increasingly need the support of smart phone apps and online services but find themselves less and less able to manage technology, see screen details, mouse and tap accurately, and type (much less type on tiny screens, given peripheral neuropathy), Henri suggested that smart voice technology (both speaking commands and receiving information) promises the most elder-specific benefit.

I imagine the elderly being able to use a smart speaker (Google Assistant, Amazon Echo, etc.) for an increasing list of tasks:

• "Call Mary!" or, just "911!"
• "Do I have an appointment today? When do I have to leave?"
• "Schedule my ride to the bridge club."
• "Raise the thermostat a few degrees."
• "Order more Orange Gatorade and toilet paper."
• "RSVP yes for the carpool to church."
• "Play back 60 Minutes." "Slideshow my photos."
• "Do I have any new email from family?"

There would also be more and more "push" assistance automation:

• "There is a new weather advisory. Rain will turn to sleet by 6:30."
• "Uber has been ordered and will arrive in 7 minutes."
• "Take your evening medications now."
• "It is Elaine's birthday. Do you want to call her now?"
• "Put out the recycling for pickup by noon."
• "Printing out medical history and medication list for Dr. Natov."

This is a major take-away that I've been thinking about: Combining smart speakers with smart sensors (data collectors on power plugs, coffee makers, motion detectors, electronic door locks, lighting, GPS wearables, and more), all manner of IoT data collection and analysis will make it possible to evaluate, track, diagnose, surface issues, and extend the independence of elders while supporting their family and caregivers.

Next year will be AustinUP's third technology summit, in doubtless a still larger venue, given that they sell out. I hope to attend and find out what Austin technology startups are doing in this space!

So, why cohousing?

Now that I'm a member of a cohousing community in development (Ralston Creek Cohousing), folks are asking how I got into it. Truth is, I've been intrigued with the concept of cohousing long before I ever heard the term. Here's where my ideas came from, best I can remember:

• As a tween, I watched The Waltons and noodled about how smart and supportive their multi-generational common house was; the older folks were able to contribute and also have the support they needed, the parents had many helping hands, and the children had the security of more adults to rely on. Living in an extended family seemed far more balanced than the nuclear family models all around me, which tended to result in too much responsibility being carried by the mother.
• As a teenager, I read In This House of Brede (see Diana Rigg's great performance), and I was deeply moved by Phillipa's letting go of her glamorous professional life and dreamy apartment in order to join the deep sisterhood of a cloistered Benedictine community. I seriously considered becoming a Franciscan sister.
• I commuted far to college and was socially isolated, but I stayed in graduate housing at UT Austin for my master's degree. Living with other graduate students from all over the country and the world, I learned how suite-style living with shared common spaces made for easy and ample companionship, and the shared meals in the dining hall were a wonderful way to enjoy that diversity of people. I was aware that it worked so well because we were all graduate students, so we shared a lot of traits (such as introversion), values, and interests. We were a tribe.
• When I joined my first software startup company, several of the founders shared a large house, and several of the single programmers lived there as well. I envied the easy, fun lifestyle they shared. And the longer I worked in software shops, the more I realized that I enjoyed them because of the type of people who tended to work there, much like graduate school, and wouldn't it be nice to extend that environment outside of work hours? to live with your tribe?
• I reconnected with an old coworker who, depressed, had quit his job and traveled broadly. Seeing him years later, I found him greatly transformed, and I learned that he had been living communally in the local Zen center for over a year. I was amazed at the benefits he'd gotten from Buddhism and from living intentionally. I wanted what he had.

About that time, cohousing surfaced. An email search reveals that I first mentioned "cohousing" eight years ago, hoping to interest my folks: "I found out about cohousing.org from a brilliant scientist whose blog I admire: http://earlywarn.blogspot.com/2010/05/odds-of-cooking-grandkids.html". Now I knew what to look for, but it was several years before my own path got serious. Then life happened: I divorced and empty-nested in the same year, so I stepped up my search for new intentional ways to live.

I started seeing and sharing articles about cohousing in Scandinavia, and I signed up for newsletters for cohousing.org and ic.org (Fellowship for Intentional Community). It was there that I learned about a Cohousing Association regional conference being held in Boulder, Colorado. Wanting the excuse to visit family in Colorado and wanting to tour and test my notions against actual cohousing communities, I splurged and attended the conference. Definitely worth it!

While in Colorado, I stayed at my brother's brand new house in a net-zero (carbon-free) development just south of Boulder, called the Geos Neighborhood. I learned that Geos had space allotted for a future condo-style cohousing unit, called The Gatehouse, just down the street from him! The community is still in the forming stage, so I joined to get in before all of the apartments were spoken for.

At the same time, I joined every cohousing and co-op group that I could find here in Austin. Sadly, those who have been working in this area for years tell me that Austin is actually one of the hardest cities in which to develop cohousing, due to the nature of its zoning codes. Just as disappointing, the CodeNEXT initiative that would have addressed this has just been torpedoed. However, there are multiple groups that are working on housing innovation, and I'm eagerly attending and supporting all that I can:

• AustinUP, a community alliance, austinup.org (I just today attended their 2018 ATX Aging & Innovation Summit)
• Aging2.0, Austin chapter: aging2.com/austin
• Shared Equity Co-op, an informal group formed by co-op veterans who are seeking to develop new co-op properties for non-students
• Armadillo Cohousing, a group that's in the early form-up stage

I'm very excited about the growing energy around making cohousing work in the United States, for more than just well-heeled retirees (although they deserve credit for driving this forward, as they look for alternatives to the sad senior housing experiences of their parents). I hope to contribute what I can to its success, as well as enjoy the experience of it! Anyone else?