Moving This Blog to from Blogger to Ghost

My new blog is hosted at http://www.looksgoodworkswell.com. It runs on Ghost, a NodeJS blogging platform.

Background

In 2005 when I started this blog the easiest thing to do was to snag a blogspot account and start posting. When I first started blogging it was really to just make notes for myself. Over time the blog became more popular and really outgrew what I would want to do with it on Blogger.

But inertia is a terrible thing ;-) I remember having a conversation with Matt Mullenweg (founder of WordPress) 7 years ago and he told me how easy it was to migrate my blog to Wordpress. I promised I would since it was a much better platform. But I never did it. Just always felt like a little less important than all the other things in life.

5 yrs ago, Theresa Neil & I released our book Designing Web Interfaces (and yes it is sorely in need of an update) and we launched a companion blog on Wordpress. I liked Wordpress, but I didn't love Wordpress. I think it had to do mostly with having to hack away in PHP. Mind you I don't hate PHP. I just don't love it. Due to this I found even less reason to move. I mean if I am going to move to a new blog platform I better really like the environment and believe in its mission.

Enter Ghost

I was really excited when the Ghost blog platform was started on KickStarter. It combined several things I really liked.

1. Markdown for Editing

I really hate writing a blog post and having to mess with a rich text editor or having to think about markup. I just want to write something. Blogger was terrible in the markup it generated. I felt dirty every time I wrote something. Not a nice thing to have run through your mind while trying to inspire the masses.

But markdown -- now that is a different story.

One of the challenges some of you that read this will face when you get a little older is it is too easy to get comfortable in a set of tools. Github certainly tipped the scale for me to awaken me to the simplicity and beauty of markdown. In fact the current book I am writing I am using the Mac app Ulysses which has a really nice markdown environment.

In Ghost, markdown is the lingua franca. It has a really nice side-by-side markdown/preview editor. You can focus on writing and not on the formatting.

2. NodeJS as the platform

In case you didn't know, I love NodeJS. It has helped us start a revolution at PayPal for our engineers and soon our customers as experiences will start rolling out faster.

The good news is Ghost is built on NodeJS. Not PHP. Not some bizarre 2001 platform like Blogger. Given that it is node I can spin up my blog locally or host it on nodejitsu (or any other cloud supporting node) or I can host it on ghost itself for a nominal monthly fee.

Knowing how your blog works -- from how it stores your blog content, how it renders it, how it gets deployed, etc. is really powerful in itself. It's also cool that I can keep my blog as a git repo.

3. JavaScript Templating for Themes

It's simple to grab themes or write your own themes. It uses handlebars templating so is really easy to start working with. If you use the Ghost hosted solution (sign up for an invite) you can just hack on your theme, run locally (or on another platform like nodejitsu) for testing and then when you are happy just upload the theme to ghost.io platform and you have your new look & feel.

Moving from Blogger to Ghost

Since Ghost is still early on, there are no direct import tools to bring Blogger posts to Ghost. What I did was use the Blogger to Wordpress export to create a dump of my blog posts. I then set up a temporary wordpress blog on one of my Dreamhost sites and imported the posts there.

Then I installed the "Wordpress to Ghost" plugin in my temp Wordpress blog. Then I was able to export a JSON file suitable for Ghost.

Because I could install Ghost locally it was easy to import the JSON file and verify that all 205 posts had made it over correctly. Of course I found issues. There were links to images stored on blogger, links to resources that were scattered all over one of my servers and some links were hardcoded to the blogspot blog. 

This gave me a chance to clean up all these links, have a better strategy for where to put files for my blog and so on. It actually felt good to clean up 9 years of crufty stuff.

I experimented with hosting the new blog on nodejitsu. The big issue right now is jitsu deploys are destructive so each deploy blows away your content (the blog database is stored in the content directory and thus pushed with the deploy). Martijn Swaagman has helpfully written a persistent-ghost wrapper for nodejitsu that allows you to install ghost with jitsu CLI and then when you deploy it copies the database out to its mongo grid, does the deploy and then restores the blog post. Yes, a hack, but it seems to work fine. I did run into an issue with running my blog locally in this configuration. The node module node_sqlite3 doesn't install correctly with node-gyp so you have to do a manual install of it.

In the end I decided to just go with the Ghost hosted platform. I figured I would get better support (you do), better analytics, better integration with their marketplace and they would worry with keeping it running and secure.

However, having the ability to run it locally or any node based cloud solution gives me peace of mind for the future. Even if they failed as a company, I have the blog software and can deploy it and manage in any way I see fit.

I started with a free theme called WillSong. Nice simple theme. I did hack it a good bit to get it to be a little better at responsiveness for mobile and added a third column for bio area, etc. But this is what is cool about the themes. They are really easy to change since it is just Handlebars, HTML5/JS/jQuery, etc. (or they could be any solution you want). Since a theme is self-contained, you just zip it up and can upload it to the hosted blog and you have the new look & feel.

Follow Me at Ghost

Please update your link to http://www.looksgoodworkswell.com for any new blog posts coming my way. Of course the best way to keep up with me is to follow me on twitter @billwscott

Hiring in Austin

My team in PayPal Austin is hiring. We are looking for user interface engineers that can span the stack from node.js up to backbone.js. As part of the change we have been bringing to PayPal, our UIE teams partner closely with our design teams following the Lean UX methodology. And instead of just focusing on the HTML/CSS/JS client bits, we also work on the nodejs server bits as well. The process & tech stack allows us to move much faster than ever before.

We recently refocused the Austin team to own the developer.paypal.com experience as well as other aspects of the external and internal developer community. If you haven't check out developer.paypal.com recently, you should. New APIs, new experience, but much, much more coming. Come be a part of this team to take our developer experience to a completely new level.

Contact me @billwscott on all normal channels: twitter, gmail, linkedin, etc.

Fluent Talk: Releasing the Kraken. Clash of the Titans: NodeJS & PayPal

In a most unlikely place. We have unleashed the Kraken.

Key Position: Sr. UIE Manager for our Wallet team

I have discussed in the past that we have been on a mission to change the culture, technology, process and experiences at PayPal. 15 months into my adventure here I have never been more excited.

Starting last year we moved away from Java & JSP for rendering our UIs and instead went to JavaScript templating (dust.js), using LESS for our CSS pre-processing, require.js for module dependency, jQuery, Twitter Bootstrap and bunch of other open source goodness. In addition, we have been using node.js as the underpinning for building our user experience code in a rapid, high iteration fashion. And even more exciting we are working on getting node.js to the point of production ready to build our app stack on top of it.

In addition, we have been pioneering Lean UX as a working model that puts our user interface engineers in the room directly with product & design to help lead our new experiences.

And we have been hiring some great talent.

Speaking of talent, I need to find a great manager for one of our most important teams -- the Wallet team. All of the consumer experiences fall under this area and cover desktop, tablet and mobile. We are also leading the charge on mobile first and the wallet team has many exciting opportunities to rethink the consumer's wallet across these channels.

Here is a link to the job description:
http://jobs.ebaycareers.com/silicon-valley/user-experience/jobid3066378-sr-uie-manager-wallet-paypal-jobs

What am I looking for? You should be passionate about all things front end. You should have a good solid history of writing and delivering front end applications in JavaScript and have a strong understanding of all of the industry best practices as well as the industry trends and key open source projects. Some experience with node is a plus.

What do I need you to do? Since the team is about a dozen in size, I don't need you coding on a daily basis. What I want you to do instead is to take this great team to greater heights. Inspire them. Grow them. Mentor them. Help instill great engineering into the team (continuous integration/deployment/social coding). I also need you to be passionate about experience. And passionate about delivering this experience to multiple channels. Ensure that we are utilizing responsive web design in every possible way.

You will need a strong working relationship with our product team, middle/backend engineering teams, and user experience teams. You will set the example for how this team gets stuff done. I need you to be a leader!

If you are interested in this exciting challenge then ping me right away. I am on twitter @billwscott or same handle for my email at gmail.com.

Indispensable Principles for Debugging - Book Recommendation

Don't judge a book by it's cover (or it's website... or it's poster). Especially true in this situation. David Agan's book "Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems" is a great find, chocked full of simple wisdom on how to find and fix bugs. Some of you will be turned off by his use of Comic Sans (see his note at the bottom of his website for his funny comment on why he sticks by his comic sans guns).

What it is not.
It is not a tutorial for any debugging tool. It is not a primer for debugging in any specific language. It is not an exhaustive tome on debugging. It doesn't have specifics on debugging for the web.

What it is.
Short and sweet. It contains 9 principles that are timeless and can be applied to any system you are trying to debug. Timeless aspect.

Why this book?
I have often wondered why some engineers seem to be able to debug and fix issues and others just create a mess when they try. Of course some minds work in a more systematic manner than others and some have more insight. This book teases out the principles that underly finding and fixing issues. The principles are dead simple and completely obvious when you glance at them. But I promise you that a lot of our colleagues don't practice even a portion of these.

I also like this book because it is a little older and it doesn't try to tie itself to the current trends. One of his first "war stories" is about debugging one of the original Pong games. Love it. First published in 2002, and then again in 2006, it is kind of hard to find. I bought the last 7 copies from ebay today but you can get it from the kindle bookstore.

Nine Principles

1. Understand the system
2. Make it fail
3. Quit thinking and look
4. Divide and conquer
5. Change one thing at a time
6. Keep an audit trail
7. Check the plug
8. Get a fresh view
9. If you didn't fix it, it ain't fixed

Do you have other suggestions for teaching the basics of debugging? Comment below.

User Interface Engineering Disciplines & Skills

One of the first things I did when I joined PayPal was rename the "webdev" to "User Interface Engineering". Now while there is nothing wrong with the title web developer, at PayPal webdevs were considered one step below a "dev".

Changing a title in itself is fairly meaningless. But at the same time names are powerful. Over the last year I believe we have been really growing into the title. Recently I started sketching all of the engineering disciplines as well as web development skills needed for this role. Here is the diagram I created.

Here is an accessible version of the diagram above.

One of our next steps is to flesh out curricula that ties to the diagram above. We are calling this courseware "Bring Design to Life University" since our job as UIEs is to bring great design to life.

List of Mockup/Prototyping Tools

Started keeping a list of these tools. No particular order.

Creately

http://creately.com/

Axure RP

http://axure.com/

InVision

http://www.InVisionApp.com

Mockingbird

https://gomockingbird.com/

Balsamiq Mockups

http://balsamiq.com/products/mockups

Ratchet

http://maker.github.com/ratchet/

Justinmind

http://www.justinmind.com/

HotGloo

http://www.hotgloo.com/

FlairBuilder

http://www.flairbuilder.com/

Mockflow

http://www.mockflow.com/

mocklinkr

http://www.mocklinkr.com/

Mockabilly

http://www.mockabilly.com/

moqups

https://moqups.com/#!/

AppMockupTools

http://www.appmockuptools.com/

WireframeSketcher

http://wireframesketcher.com/

JustProto

http://www.justproto.com/

Napkee

http://www.napkee.com/

ForeUI

http://www.foreui.com/

Jumpchart

http://jumpchart.com/

Protoshare

http://www.protoshare.com/

iPhoneMockup

http://iphonemockup.lkmc.ch/

Lumzy

http://www.lumzy.com/

Pidoco

https://pidoco.com/

Proto.io

http://proto.io

AnteType

http://antetype.com

AppSketcher

http://appsketcher.com

MockupBuilder

http://mockupbuilder.com

PowerMockup

http://powermockup.com

AppCooker

http://www.appcooker.com/Overview.php

Tiggzi

http://tiggzi.com/home

iPlotz

http://iplotz.com/whatisiPlotz.php

Serena

http://www.serena.com/products/prototype-composer/index.html

fluidIA

http://www.fluidia.org/

FrameBox

http://framebox.org/ECIN

Naview

http://www.naviewapp.com/

DENIM

http://dub.washington.edu:2007/projects/denim/

UIreframe.com

http://uireframe.com/app/

GUI Machine

http://gui-machine.com/

inPreso Screens

http://www.inpreso.com/inpresoscreens/

UXPin

http://uxpin.com/

SoftAndGUI

http://www.softandgui.co.uk/

Notism

https://www.notismapp.com/home

MockupScreens

http://www.mockupscreens.com/index.php?page=Screen-Prototypes

MockupTiger

http://www.mockuptiger.com/

JotForm

http://www.jotform.com/

Keynotopia

http://keynotopia.com/

Handcraft

http://handcraft.com/

Added after original publishing of this article:

LucidChart
http://www.lucidchart.com

Twitter Bootstrap
http://twitter.github.com/bootstrap/

JetStrap
http://jetstrap.com/

Lean UX & Agile Development. Rationalizing the Two Methodologies

I really enjoy Silicon Valley Code Camp. Lots of speakers, lots of local attendees. Very informal and always a good crowd. No different today. Really engaged audience.

One topic I covered was how Lean UX and Agile work together in harmony. Here is a diagram I shared that I have been using at work to explain how they are related and how they are different.

Agile focuses on iterative delivery. It is by nature engineering-centric (though it has been applied to non-engineering tasks) as it produces software meeting specific acceptance criteria. It has numerous ceremonies instead of heavy process like waterfall methodologies require.

Lean UX focuses on refining the experience through collaboration, shared understanding and continuous customer feedback. While agile finds its roots in engineering, Lean UX stems from work borrowed heavily from Eric Ries in the Lean Startup and applies it to refining customer experience. Lean dispenses with agile ceremonies but like agile also dispenses with extraneous documentation. Lean UX gets its cadence from getting prototypes or mockups in front of customers regularly while agile gets its cadence from delivering working software released at the end of each sprint.

In the above diagram I call out this separate stream of work -- the Lean UX stream. It is separate from the agile streams, but does not replace the agile streams. It runs ahead of the agile streams like Sprint 0 methodology but it does not stop with sprint 1 (nor is it confined to starting one sprint ahead). It continues to run in parallel with the agile tracks. What gets learned in the LeanUX stream (essentially a continuously evolving living prototype) gets fed into the agile streams and becomes some of the user stories. Its cadence may change (we usually start with weekly usability testing and then slow down to every 2 weeks or so) but its purpose does not. Separately I have noted the technology changes we have introduced that allow us to have seamless movement between Lean UX streams and Agile streams with respect to software delivered. This is an essential ingredient to making this work well.

Lean UX & Agile work together well. And while they share lots of common principles they are distinct work streams. Lean UX & Agile aren't the whole picture on how to create great products. You also need to be able to gather customer insights, define customer problems, refine solution concepts, deliver & test solutions and then rinse & repeat these steps. Lean UX is one tool to help us refine & test solution concepts. Agile helps us deliver solutions. A/B testing helps us test what we deliver. Customer driven innovation (pioneered at Intuit) defines a broader methodology that Lean & Agile fit nicely inside of.

Ok, so with that context here are the updated slides from the talk I gave earlier today on Anti-Patterns for Lean UX. You can see an earlier version on slideshare.

Are you using Agile & Lean UX methodologies? How are you approaching innovation & experience delivery in your organization?

Three Key Principles to Operating as a LeanUX Team

Coaching teams here at PayPal on what it takes to operate like in a LeanUX manner. I have typically boiled it down to just 3 key principles.

Three Principles

1. Maintain a Shared Understanding at All Times

This was key when I was at Netflix and I see it even stronger now. A lack of a shared understanding means you will have have to lots of documentation. Having documentation that is predictive in an iterative environment is problematic. It is not realistic since you need to be able to change assumptions and solutions early in the cycle. Historical documentation becomes more necessary as teams downstream need them.

A good way to alleviate much of the documentation normally needed is to pull the teams that are normally downstream (like QA, Localization QA, Localization, etc.) and bring them up further in the earlier cycles. Additionally you can create tools earlier in the process that proxy for these teams and reduce the number of those representatives you will need. Tools downstream should be automation driven as much as possible.

In a recent LeanUX project I kept referring to a/b testing. At some point it became apparent that not all the team understood what I meant by a/b testing (remember this is what I ate, drank & slept at Netflix). It was an easy solve to get us a shared understanding, but the mistake was assuming we had one already on all topics.

2. Collaborate, Collaborate, Collaborate

Walls between teams get erected whenever teams get big, become overly specialized and work in isolation. Agreeing to work as a team, trust each other and make collaboration the underpinning of the team's ethos will ensure the walls will come down.

It's not easy. We like to retreat back to the comfort of going solo or dictating to another the way things work. How can you tell where the walls are? It will be at those hand-off points that happen across disciplines. Collaboration is the opposite of this toss it over the wall mindset.

It's ok for teams to take time to work separately or have sessions to reflect. But if you are doing this to avoid working as a team then watch out. Trouble is already at your door.

3. Build/Test/Learn -- or Get to the Customer Early & Often

This is the secret to getting rid of team politics, getting rid of the prima donna, getting rid of analysis paralysis. Getting to the customer in usability tests, research, a/b testing and so on and doing it on a weekly or bi-weekly basis if at all possible keeps the team pure. It is the difference between a stagnant pond or a clear lake fed by streams. User data & user feedback will keep the team focused on the customer and the real goals of the product. 

Believe me this really works. It is astonishing to see how much ownership takes over the team when they sit in all the usability sessions as a team and watch the successes and failures of their work. I have seen the full team time & again go out of a session that didn't go so well with a renewed determination to nail it next time. Customer feedback is the elixer to what ails you (now I just have to mention that all of the standard practices of how to gather this feedback and what to do with it still apply).

It's Pretty Simple

Fragile is often the name given to agile projects that are busted. I have used the term "Lean-Fall" to describe that ugly mix of waterfall & LeanUX. When I talk with teams that are struggling to work in an agile manner it could be a host of issues. There is a lot of machinery from an agile practice standpoint that might need tweaking.

But frankly, over and over I have seen it come down to one or more violations of these three principles. If you don't have shared understanding, collaboration and continuous customer feedback, no amount of scrums, scrum of scrums, agile coaches, etc. is going to make a difference.

View what you are doing as a team in light of these principles and see if it doesn't give you a fresh perspective on acting like a startup.

If you like this article, you might want to check out my Anti-Patterns for LeanUX presentation.