Subomniactating: Definition

Subomniactating is a useful word for discussing the process of throwing a person under the bus. Like at work, after a bad meeting, or when blame needs to be apportioned to someone other than yourself. Or when a new task or project is particularly unpleasant and likely to result in pain or sadness, you may want to throw a person under “the bus”. Subomniactating will occur.

Inspired by the amazing word defenstration (throwing a person out a window).


Conversational UI Design and Prototyping with Bottery

Remember last year when everyone was super excited about conversational UI and chatbots? Maybe you were like me and thought “ooh that sounds interesting but no-one actually needs me to design one now… 😦” Well, guess what. 2017 is almost over and I finally had the chance to work on the UX for a chatbot. I mean, I had made fun silly chatbots which spouted random nonsense using markov chains generated from the text of a long running work chat channel. Which was fun. But it didn’t exactly require any “design”.

So this new chatbot is for a client that has a really good use-case and idea. The bot is in early stages of life, but it is available in the slack directory now, and it’s is really buzzword friendly (“machine learning!”, “gamification!”, “computer vision!”). Anyway, it’s actually cool but I needed some way to analyze and improve the UX. There’s a lot of different things to think about, so let’s break down what I’ve done so far.

1. Use the thing

Install it, interact with it, understand why it’s cool, what’s ugly, what’s just half-baked. Also use other competing bots on your same platform so you can see how other people have solved particular problems. The Slack API offers some interesting extras like slash commands, buttons, and dialogs. Know how those work, skim the technical documentation so you understand the limits.

2. User journey maps

Think about the real-world context of a user who is going to interact with the bot’s primary function. Where are they? Are they on their phone? What’s the Job to Be Done? What is their emotional state? What external distractions and competing motivations will you have to deal with during the interaction? Graph it out. Ask questions through documentation.

I found it useful to break down this type of interaction into 4 phases.

  • Desire
  • Initiation
  • Follow-through
  • Satisfaction


This gives you the chance to think about the “happy path” and also see where exactly are the places the user might “exit” the journey too early.

3. Pixels and Vectors

I know this is where designers usually start, but you can now start drawing up wireframes and designs in sketch (or Affinity Designer or Adobe XD) for specific interactions that bring the user out of the chat user interface for things like payment, upgrades, account registration. I like to draw flow lines from buttons to next screens. Creating an invision prototype isn’t a bad idea even though you can’t really type anything into your fake slack windows.


Mocking up the slack windows is important to really give your brain some context and to be aware of how visually jarring it might be for a user to have to transition out of the chat interface to a web-browser and back.

4. Actual Interactive Programming!

This is where it all get’s interesting. Go download bottery from GitHub. Google provides it as an open-source project. It’s a little technical but basically you need to follow the instructions in the readme. They walk you through creating a simple “kitten” bot. The code is all in javascript, so I hope you’re comfortable with that. Remember to provide all those commas otherwise nothing works!!!

It’s a lot like designing a text-adventure actually. Entrances, exits, storing variables. Technically you’re defining a “finite state machine”.

Tip: One other thing the readme doesn’t say is that you need to run the bottery app from a local webserver. Which is super easy if you have node installed. You can open a terminal and type npm install -g http-server then, change to the directory where you downloaded or cloned bottery and run http-server -o.

I started to realize that it was actually useful to go through the practice of writing each prompt and state of the bot. Using it in a real interface makes you understand the tone, makes you think about grammer in a whole new way. It’s personal and conversational, so you have to think about tone in a totally different way than we are accustomed to when writing web micro-content. I decided to make my bot a little funny and sarcastic like K-2SO from Rogue One. This happens naturally as you start trying out all the different paths. You see the need for unique states that respond to the user’s data in very specific ways. English grammar is hard and writing english grammer that is adaptable to even a few variable is surprisingly difficult.

Understanding the different variables you are capturing from the user and writing out consistent vocabulary words for different random injections in the script is important to this phase of design.

We need to think about what we are saying to the user, is it getting stale and boring quickly? The randomness of having the bot pick different words for different ideas during each conversation offers a little bit of delight in each interaction.

chatform bottery


Design Systems Documentation in a Wiki

I’m reading the excellent book Design Systems by Alla Kholmatova and it’s been a great resource so far. I would consider it to be a higher-level companion to Brad Frost’s Atomic Design book, which I read early this year. Neither of these are very long books, and as a relatively new freelancer I love the freedom of getting to buy books to improve my skills as a business expense.

The idea behind this Design Systems book is to provide a lot of the answers to “why” are design systems important, and “how” to start with certain mental exercises before even creating a design system. The prep work in the foundations section of this book is really excellent and inspired me to look for another new way to implement a design system for a client.

design systems

As I work with different customers I think about the best way to provide deliverables to each team. I’ve created big PDF’s full of visuals when that is the best option, and I’ve created styleguide web apps stored in a git repo… but, I really like the power and flexibility of the Wiki for detailed and in depth documentation. Wikis are easy to share with a team and collaborate in, easy to search, and easy (easier) to maintain.

Recently I had the opportunity to use the excellent Confluence from Atlassian with a new client and it is a great tool for building a pattern library. I’m calling it the “UX Library” and it contains the following major categories:

  • Design Principles
  • Personas
  • Functional Patterns
  • Perceptual Patterns
  • Modules
  • Vocabulary and Tone

There are two great features of Confluence that I’m using, (not sure if you can do this MediaWiki or DocuWiki)

First, creating Page Templates for new patterns of certain types to make it clear what each pattern should contain.

current template screenshot

Second, I’m creating Clickable User Journey diagrams that map to the specific pattern or module that the diagram box the user is looking at.

pattern map diagram

These give the internal audience a visual way to quickly find the overall flow and the specifics of each interaction.

All together this makes a wiki a great tool. It becomes a living, and maintainable UX spec for the entire product or across the company with multiple products implementing similar patterns.


TypeScript with Vue.js is the Perfect Fit

On a couple recent projects I have had the opportunity to build web applications using modern JS frameworks. As a self-employed UX Dev I have to balance the fun of bleeding edge technology with the need to be productive and efficient with my time. I’ve done enough little projects with Vue.js at this point to know that it’s my frontend framework of choice. It’s very easy to learn, and fun. It keeps simple things simple.

The best part about building apps primarily with JavaScript is the rapid prototypes and ability to see changes reflected quickly. The Vue webpack templates with hot-reload make this even better, because as soon as you save a component file or SCSS stylesheet you see your change reflected in the browser window.

Vue is a JavaScript framework, but I’ve seen the light of strictly typed languages when I had the joy of developing in the C# world in my recent years. So, now I think that the extra discipline of using TypeScript is well worth it and you get to use brand new language features right away, like async / await and decorators. I’m not certain that decorators are the best thing ever, but I am using them a lot in my recent vue projects because of the wonderful work in vue-property-decorator.

Currently for a server backend I’m using CouchDB which is an excellent choice for web apps that need a data persistence mechanism that resembles “document” storage and especially one that needs revision history… also it’s super-simple to run locally for development on all platforms. And the amazing browser database library PouchDB is the perfect interface for it giving the user offline document access for free.

So, the combination of these elements: Vue, Typescript, and PouchDB/CouchDB make for an excellent application building platform. In the JS development world there’s a lot of interest in the data state management solutions like Redux and Vuex… but, I haven’t used them. I haven’t needed to yet. PouchDB and TypeScript decorators provide a lot of powerful data management flexibility and repeatability so I don’t see the need yet for all of that extra ceremony.

For hosting I definitely can recommend Netlify for all of the static frontend code.

For source control I can say that bitbucket is back on top in my mind, with it’s latest addition of Trello board integration.

I still need to settle on a decent user authentication and user data-storage scheme. I still think Azure Table Storage with it’s concept of PartitionKey and RowKey is a useful pattern which I consider going back to from time to time. Especially when CouchDB on the server has me editing config files through vi late into the night…

I’m really happy with the way Vue, TypeScript, webpack, and the related libraries work together to give me everything I need to write clean and readable and fun frontend code. Here’s the big things I’m still searching for answers to:

  1. User Authentication, Auth0 is nice but it worries me to put such a critical collection of your customer information in a service provider’s claws.
  2. Server-side API logic … you can try to write all your app logic into CouchDB actually… something to consider. I’ll probbly default to a Nodejs express app hosted somewhere like Heroku or Azure. Or a ASP.NetCore API. And then there is serverless options for me to consider.

The web development tools have gotten really powerful and really fast but the learning curve to even get to this point has not been small. And some careful consideration still needs to be had around architecting data persistence and user management. Also, seriously I can not figure out the Google Cloud Compute pricing for virtual machines once my free credits expire.


Hosting static websites with continuous integration for free

It seems like I’m always creating another website. I’ve used many different hosting solutions during my decade-and-a-half of experience on the web. I’ve always been on the lookout for a better publishing and hosting setup.

Currently I am enjoying using a static website generation tool, specifically hexo which is built on node and let’s me write in Markdown.

When I put my blogs up I need only a very simple hosting solution. I’ve tried using Amazon S3, and traditional cPanel shared hosts at Bluehost and I’ve used heroku, and Microsoft Azure. But currently my new favorite platform is netlify.

The free tier at netlify is amazing. It gives you super simple connection to git repositories and great continuous deployment from the repo. This means I can write on my smart phone using a text editor and a git client, then push the changes and have them built and deployed automatically. Netlify also gives you some nice DNS tools and easy ways to register for an SSL cert with LetsEncrypt. These are all the things you need for a modern website. You can host any static content, like javascript-heavy single page apps that tap into an API hosted somewhere else, or you can create a serverless API on AWS lambda for pennies per month.

For a blog or basic brochure style site it’s perfect. I’m in the process of moving all of my various personal websites over to hexo on netlify.


The Best Reading Light


Sometimes I just walk by something and have to capture it. This new phone really does have a good low light camera. Our littlest guy is getting so big, and he loves “reading”.


Use Source Control When Hiring Freelance Developers!

I see this too often - a directory on a server full of files like …


This is a sign that the developer was scared of thier changes… and they weren’t using any sort of source control system to let them revert their change. A source control system like “git” keeps track of every single line-by-line changes to every file in a project and allows multiple developers to make changes concurrently to the same project.

When I restarted my freelance business I hoped client expectations had moved up to the point where every customer asked for this. I didn’t think clients would still allow a developer to just log directly into their server with SSH or FTP and start pushing files up or editing directly.

Don’t Let Just Anyone SFTP Files Onto Your Server

  • What happens when your web host crashes or has extended downtime? How are you going to deploy your code to another server?
  • What happens if you are hacked? How will you get your site back to a known good clean state?
  • How will you roll back and fix any mistakes or malicious changes?

Doing It Right (It’s Called DevOps)

  1. Go sign up for git hosting at bitbucket or gitlab or pay for a private repo at github.
  2. Then hook it into a continuous deployment system pointed at your web hosting dev site - so that every time code get’s pushed to the master branch that code is deployed to your dev server and it can be reviewed there.
    • Azure Websites has a great hosting setup UI and Continous Integration support from popular Source Control Systems (even dropbox!)

If you’re hiring a freelancer for development, you can probably also find a freelancer to set up the source control repository and continuous deployment if the other developer isn’t comfortable getting it set up.

That way no code can make it onto your server without being stored in a private git repository.

Bonus points: make the developer use environment variables for any api keys or environment specific usernames passwords that the site uses. This way the dev can use dev keys and you keep your production keys private, and they don’t get leaked in the source control system.


Style guides - Documentation or Workbench?

Brad frost has posted something about styleguides that I find really illuminating:

He talks about the difference between the place where you work and iterate to create the output, and the place where you show that ouput off to the users. This seems obvious now that I see it, but it was foggy until now. When we become styleguide producers or design system designers, then we need to think about shifting the process back one more step. Sometimes we produce a system for a large organization (or the public) to use and that sytem has to be really clean and well organized and the documentation needs to thorough, maintainable, attractive and usable. But, we still need a place to build those design components and test them iteratively without commiting everything fully to JS or back-end coding.

The patternlab tool that I grew to love during my first styleguide project has not been the my final choice for the last two style guides. This has been for a couple of reasons, but mainly because I needed something that would integrate tightly with an existing web app codebase. This would help keep the patterns up to date with the actual production code more easily. And one thing I especially love about design systems is that developers can grab a copy of it and do rapid front end dev without needing to run the full development environment and incur the time delay that comes from the extra overhead.

This all leads me to a place where I was creating style guides that are both workshop and storefront in one, they were supposed to be a place for collaboration and iteration amongst developers and designers, but they also needed places for lots of documentation. This lead to a hybrid construct where static documents were being combined with component modification workspaces. On my most recent system the dev team had already built hundreds of React components, and the scss files were being loaded directly in the coponents. Now instead of trying to force them to rearchitect all of their SCSS and make them convert React components into mustache templates for patternlab I looked for ways to convert them automatically. I tried this project on github and I even tried building my own grunt task that could do it, but I realized it was just becoming too disconnected from the original JS codebase. So I went back and found a project called React Styleguidist which they call a “component workbench” (see!) that was just right for that use case, and I was easily able to extend it to serve a custom layout and create extra documentation pages using static markdown files.

So far, combining a “workbench” with a documentation site has actually worked out well for these smaller systems, but I saw immediately what Brad was talking about with the need for separation and abstraction when these systems get bigger and have bigger audiences.

Our understanding of the needs of our users has to shift from the end-user to the internal developer and designer when we make the shift to becomeing system designers. And I encourage you to think about the needs of your users carefully every time you start a new style guide, think about the technical advantages and disadvantages of all the tools out there and dont be afraid to get your hands dirty and create something new and unique for the needs of each company or team.