Announcing PubCleaner for Kindle

I hope to work here and there on my own projects more often, and actually get them released to the world. So here is the first. PubCleaner is a tiny Windows app that very simply deletes all *.pobi periodicals from your Kindle except the most recent one of each publication. Warning: it is very early in development!
PubCleaner
PubCleaner project page on GitHub

Artifacts that can improve UX

Yesterday at work, we gathered in a conference room to hear from Jay Mathews of Straight Line Media on user experience and software design. 
How can any of us understand a design from a list of requirements or even user stories? How can we hope to communicate with product owners and stakeholders what we propose to build? Mathews suggested these artifacts:

• Low-fidelity sketches (6-8 hours for many) of a proposed GUI are typically created with a whiteboard and can quickly generate and communicate ideas and discussions to try to find a working approach. Drawing out several sketches can allow us to combine vastly different GUI approaches to come up with a better visual design than we can fathom via requirements alone.
• A vision document (2-8 hours) answers the question “what are we building” at a high level. Perhaps it is just an overall definition of the system, four meaningful paragraphs of detail, and/or a visualization of the system we intend to build.
• An experience map (10-15 hours) can describe the end-to-end experience for users
• I discussed personas in earlier blog posts – formalizing our personas help us understand about our users and get on the same page.  It helps get us out of our own experience and bias and reveal what we don’t know about
• Much like a user story map slice or customer journey, a scenario a set of interactions that a persona would interact with the software system.  Scenarios are story-driven, told in human terms, focus on what the user can accomplish with a yet-undeveloped system.  The user’s outcome, overall experience, and emotions are the focus here—not merely what they can do with the system.
• A conceptual architecture diagram (15-20 hours) answers “how is the overall system going to work". It overviews both the concepts and the core structure of the proposed system.
• Detailed site architecture diagram – depicts all unique pages/screens of an application and where each lives in the application’s hierarchy.
• A user flow diagram details the path a user follows to complete a specific task.
• Wireframes (3-6 hours each) communicate fundamental details about the functionality, content, navigation, and interactivity of a screen or a page. This sometimes is the final deliverable of a design.
• Prototypes (8-20 hours) help us to visualize a specific interaction with actually functioning software.

(Mathews mentioned that Agile “user stories” are “more like requirements” and thus differ from scenarios. I’d argue that the distinction between requirements and user stories is very important; indeed, both are different from scenarios.)
I believe that the best software results when we value working software over comprehensive documentation. That doesn’t mean we dismiss creating these artifacts, as some misunderstand Agile to demand. Instead, we create just enough of these artifacts as needed to create good software, and no more. We must constantly be examining ourselves to see if more documents would be useful. These documents can be highly polished or quick-and-dirty, whatever is appropriate for your purpose.
Mathews also encouraged us to do usability testing, and I completely agree. He said, “Small improvements can yield big results.” Testing with even just a few users can reveal flaws that are crucially important to fix. He recommended a formal session with a trained facilitator, but any usability testing is better than none. I’ve seen numerous ways of doing real user testing; one promising service is YouEye, where you can in mere minutes get a usability test going for any public web site.
To Mathews, UX expertise is nothing but the intersection of empathy, analysis, and intuition about our users.  We must visualize our projects—the visualizations don’t have to look pretty, but they do have to communicate what we are going to build.
Mathews recommended Goodwin’s Designing for the Digital Age for more on these topics.

Customer Empathy

Over the last five years or so, there has been a shift in the practices and attitudes of the software development community to be more user-centric. [Good blogging means avoiding big long text-only posts, so I will attempt to illustrate this with some really janky SmartArt below.] We used to invest a great deal of time trying to figure out how our software should work to benefit the business. The presumption was that we have a pretty good idea of what will work--the real challenge was designing software that can be developed, tested, and deployed efficiently. Let's call this feature-driven software planning.

The flaw in this approach is that the user was a afterthought. Release after release happened without anything but the most ad-hoc, reactionary user input. So we thought we'd bring the user's point of view into planning, and things got better. We realized that if we start with the user in mind, and did our best to avoid focusing on systems, features, or capabilities, we end up doing the more important work and avoiding lots of unneeded work we otherwise would have attempted. Our definition of “user” expanded to include everyone who uses our software, even indirectly. Let's call this  software planning. (There’s lots out on the web on the benefits of user stories; also, see Cohn’s User Stories Applied.)

Things got much better, but we still relied on our own ideas and biases to form our concept of what the user wants. It helped to gather feedback and survey data about our users, but we soon found out that just implementing what the user says they want leads to strange features and unbalanced software. We shifted to thinking more about what the user truly needs—what they are trying to get done.

The key to better planning, then, is not user feedback or user input, but getting better at user empathy. We have to put ourselves in the user’s shoes. We need to listen and observe our users, and get really good ideas from what they do, not simply what they say (or yell). We need to combine insights from user empathy with our own vision of the software as a whole, always allowing the user’s needs to override, tweak, or confirm our vision.

 

David Hussman, at the Code Freeze 2013 conference, spoke on user empathy. Hussman outlined a few techniques and attitudes we can use to get better at having user empathy. The assumption is that better user empathy will lead to more business value, because meeting the users’ true needs will lead them to value your product and use it (and your other products) more.

First, let’s stop asking ourselves, “What can I make for my users?” and instead ask “Where can I take my users?” No software product is an end in itself—they all take the user closer to something: to making money, to saving money, to a entertaining experience, or to buying a valuable product.

One way I try to do this is by avoiding business-speak in planning, and trying to shift the dialog into the user’s terms. I’d rather not talk about what the marketing department has named “engagement actions”, but instead “helping the user enjoy the browsing experience” or “helping the user learn and enjoy the food-preparation process”. In the end, the functionality resulting may be similar with both attitudes, but more often then not, the latter attitude yields software with better usefulness and fewer unimportant, unused, or underused features. 

As a more specific example for a food site, rather than providing a better web component to display a recipe with higher usability, I’d rather ensure the user can view a recipe in ways that help them to cook it, get ideas from it, and share it. I’d try to avoid discussion the feature of displaying a recipe before I start to think of where I want to take the user who happens to be using this feature.  Where else could the user go?

Secondly, we need to inject some humility into our software planning. I don’t know our users, and neither do you know yours.One effective and inexpensive way to do this is with real user testing over the web.  Another way to refine what you already know is with user personas, which can be brainstormed in just an hour or so to help guide your planning process. While personas do make explicit what you already know about a user, they also reveal what you don’t know sooner.

If someone calls me arrogant, I get defensive and argumentative.  Let us define arrogance as the difference between what we think we know and what we actually know—if we do, it is easy to acknowledge that we all have some arrogance, right? We must make the assumption that “I am by nature arrogant about my users” part of our attitude in software planning.

Thirdly, our very thinking needs to be story-based. There are two sides to this—first, we need to be thinking in “User Stories”, rather than features, as mentioned earlier.  Once we’ve started to do that, however, we also need to be thinking of actual user stories in the proper sense of the English words—a short narrative about what a user does or did, and what happened as a result.  These stories are probably best told orally, with a beginning, a middle, and an end.  They might have plot, characters, dialog, and a theme.  In other words, we can learn more about our users from a informal story about them and their experience, rather than starting with formalized user stories.  Hussman recommended finding the best storyteller that interacts with the users. Some people are naturally gifted at storytelling. Sometimes, this person is marginally technical—even better.  Have that person start telling the story, and pause to write out actual formal user stories from which you can start to develop software—remembering that a formal user story is just the beginning of a conversation that leads to working software).

Too often, teams write user stories as just gussied-up requirements (“As a user, I want the system to…”), which totally misses the point. Starting with a real storyteller can help us to avoid this feature-itis. Other times, we form well-written stories from the user’s point of view, but we didn’t spend enough effort to consider what’s truly important for the user—we only converted our feature requests into good “user” stories, without actually caring about the user. Using these techniques and many others, I hope we can increase our user empathy in ways that drastically change our planning meetings and lead to better, truly user-centric stories and software.

These stories can be created by and/or visualized in a story map, where the stories are layed out in the order the user experiences them and with relative importance/depth.  Now think back to the original question, “Where can I take my users?” Find the most important or valuable paths through the story map. Hussman called this a slice or customer journey. Identifying the user journeys (several stories that together make a valuable accomplishment) can help you figure out what the priorities and releases should be in a user-centric way.  [Hussman and his company, DevJam, are working on a yet-unreleased web tool called CardBoard to enable this mapping on the web.]

So, how’s the customer/user empathy on your project? Let’s make it better!

UX in the wild: “What do you want from me?”

I was recently looking into opening a CaringBridge web site, since I have a special needs daughter with an undiagnosed genetic syndrome. Trying to sign up, I encountered this page:

As an aside: do they even want men to sign up for this site?  Pink and hearts and lowercasing and round fonts and flowers and puppies and rainbows pervade this site, on this page and other pages.  But I digress.
More importantly, notice the form in the screenshot above. I was somewhat puzzled as to which options to choose. Hmm, myself or someone else. Am I creating an account for someone else, on their behalf, or am I creating an account site to benefit someone else, but it is my site?  All I am prompted with is “who is it for”?  I decided it was for my daughter—it is for her benefit, but not for her personally to use.
That was a pretty easy decision, but then I’m confronted with the first name/last name fields.  Do I type my name or my daughter’s name?  Again, the direction is ambiguous.  I started typing my name, presumably because I’ve done this before on hundreds of web sites. It makes sense to me that I would perhaps type in my daughter’s name in a later step.  However, a few clues told me otherwise—the fields are indented under “someone else”, and the following field is “enter your e-mail”, making me guess that the name fields are not asking “enter your name”.  Also, the submit button (properly left-aligned but improperly indented) is labeled “preview site”, telling me there relaly is no step 2 (despite the 4 numbered circles listed at the top) and it would only make sense to put my daughter’s name on this field.  I entered her name and was able to get the preview of my site.  My guesses were right.

The design of this page forgot Jakob’s Law of the Web User Experience: people spend nearly all of their time on other web sites, not yours.  It was only a small gaffe, and the page contained enough clues for me to figure it out, but how many hundreds of users had the same confusion I did?

Incidentally, we also see that we should serve your target market first (here, moms) but don’t alienate your largest secondary market (dads) in the process.

Hat tip to Kamran Ayub for the “Experience in the wild” idea. Others have done this a lot, but I was just reading a few such posts from his blog.  Thanks, Kamran!

Visual Studio 2012: The new Team Explorer and Pending Changes windows

The old Team Explorer in VS2010 (right) was simple and got the job done without a lot of finesse.  It really was nothing more than several aspects of TFS shoehorned into a tree view, grouped by Team Project.
Totally separately, the old Pending Changes window (below) offered some nice features, such as filtering, conflict resolution, TFS work item association, and undoing changes, as seen below.
(You only use these windows if you use any aspect of TFS; if you are avoiding TFS at any cost, you can skip the rest of this article.)

The new Team Explorer (right) has several rather major improvements.  Here are the new features that I notice, with a few screenshots so you can visualize these new features.

• A new Home view summarizes everything important and provides links (rather than tree branches) to each team-related functionality.
  • We now work on one Team Project at a time, changed easily by the select list next to the “Home” title.  This is a great way to avoid wasting screen real estate.
  • Web-style navigation is provided, with Back, forward, home, and refresh buttons. 
  • A feature I love is a project-global work item search, right there on the home view.  So often one or two words (or a work item number) will let me find the task or story I need.  No more do you need to go to the TFS Web Project Portal to search by work item number!
  • The search supports several special terms—helpers for which are in the drop-down. For example, T:"Task" will limit your search to tasks only.
  • A link to Pending Changes are shown with a link to the Source Control Explorer.  No more drilling-down to browse Source Control—it’s right there on the home page!
  • Work Items, Builds, Documents, and Settings work much like in VS2010
  • There is a link to the Web Access (TFS Web Project Portal) right on the home screen.
• The Pending Changes section (below) is all new and built-in in the Team Explorer, totally replacing the old Pending Changes window.
  • Again, you can change team projects right next to the “Pending Changes” title.
  • A workspace select box is immediately below that.
  • The Check In, Comment, and Shelve controls are easily available. 
  • Lesser-used actions (find shelvesets, resolve conflicts, undo all, manage workspaces) are hidden in the “Actions” select control.
  • We have two separate sections of included vs. excluded changes.  This is a much better paradigm than having to fiddle with checkboxes in one big list.  Simple text controls are provided to manipulate these lists.
  • A simplified way of adding related work items is here; the default direction is to simply drag the work items in to a drop target.  This makes a lot of sense to me, as I have to look up the item anyway, and I probably have it open in a different window.  If you prefer to do it in this window, you can—either by looking it up or by typing in an ID.
  • Finally, specify reviewers in the notes if you are using the TFS reviewing system.  If not, just collapse this section and ignore it.

• The Work Items section (below) is not substantially different than in Visual Studio 2010.  A few differences:
  • There is a “My Favorites” drop target for you; queries dropped here will give you a summary of the work items in that query.
  • A handy “New Work Item” control at the top seems useful.

New in the Builds section (below):

• The most recent builds with their red/yellow/green status
• A drop target for My Favorite Build Defintions, also with a summary
• A quick filter/search box.

All in all, these are some very nice and unexpected feature enhancements here in the Team Explorer window.  I hope they make you more productive!

Visual Studio 2012: The Test Explorer

I’ll be blogging just a little bit about some of the new features of Visual Studio 2012 that I notice as I use it.

Take a look at the new Test Explorer window.

This is a much simpler, robust interface than was available in Visual Studio 2010. By default, it provides you with groupings of tests by disposition (failed, skipped, passed, not run).  Rather than having to open up a new window to investigate the cause of a failing test, the same info is shown on the right.  Other nice touches include:

• A progress bar that turns red when something fails
• A compact display of elapsed time for each test
• Run all tests with one click when no tests have been yet run
• Run failed tests, skipped tests, or any of several common groupings from the toolbar
• The ability to right click and run a single test, multiple selected tests, or a group of tests
• Toggle “Run tests after build” so that the tests will run automatically
• Filter tests by a search term
• Tests run faster than in VS2010
• Previous test run’s results remain as greyed-out while the current test run is running
• Group test results by duration (really handy for focusing on improving the slowest tests)
• A red-yellow-green summary of all tests
• No more “Exceptions has been thrown by the target of an invocation” errors (I hope!)

These features are all new since VS2010.  This new window will totally replace both the former Test Results and Test Runs windows for me.  I’d expect this window to be open early and often throughout the development experience.  The test Explorer is docked left by default, but I’ve moved mine to the bottom as seen in the screenshot below.  Enjoy!

How can I write WPF efficiently?

When I first learned about Microsoft's then-new framework for developing desktop applications, WPF, I thought that one of the biggest benefits of it would be its efficiency.  After all, I already know what the GUI controls and elements were that I wanted to use--I just have to slap them all on the page and then wire up all my bindings right, and I'll be done.  After that, I learned about the MVVM pattern, which promised clean separation of concerns within my WPF app.

I thought this was going to be great!  I got into creating several different admin and data entry WPF apps with my team at work, and thus I began to crank out working software with robust but simple GUIs, right?

Not so fast, there, cowboy coder. My experience is that writing WPF is S-L-O-W.  

Well, at least the way I do it.  You see, after I have a picture of my GUI on a whiteboard, I code up the XAML with the controls that I want.  This part, as expected, is fast--laying out the whole of a window is pretty quick. After that, its all the little stuff you want these elements to do takes awhile. I always seem to want to make this text bold in some cases; show a red error box in these other cases.

Then things unravel: this binding isn't working right over here--I have to write a converter and adjust the layout for the right values. Whoops, I forgot that extra NotifyPropertyChanged there. Oh, and I want to use a different template in this state vs. that, so I have to figure out what I can use to swap the templates in certain situation.  This data is coming in asynchronously, so I need to make sure the right thing is happening on the right thread and that Property gets NotifyChanged as well.  Crap, when I maximize my window, it doesn't stretch like I thought it would--must be because its container height isn't defined, but I don't want to define that, so I have to make it stretch in its parent.  Oh, now I really want to make a user control out of this stuff over here, so I better implement some dependency properties...

On and on I go, spending hours and days on stuff that just feels so small and minor. I soon resort to cutting usability features and look-and-feel enhancements because this is taking just too darn long.

Does anyone have any tips or principles I need to try in order to write WPF efficiently?  I'm off to search the tubes for some thoughts.

Edit: added link for StackOverflow question.