Ellen Beldner

UPDATE: I have found where the nerds have discussed such things: StackOverflow which I <3.

---

Which is why at work I'm taking on the (currently not-unmanageable) job of responding to customer support requests.

However, I'm finding that gmail (we use google apps) is not really a good interface for doing this quickly. I want to be able to do things like bulk respond to a set of emails with the same message... Gmail has the canned responses plugin, but that doesn't cut it -- it's too slow to use.

So I just hooked Thunderbird into our support queue, and now I'm trying to figure out how to configure or optimize it for processing customer support emails. I'd also love it if it automatically kept stats or some how output to a CSV file on the number of emails processed through canned responses.

Or maybe I just need some lightweight CRM software. Hmm... I wonder what the best CRM solutions are for a small business? and how much can I expect to pay? If only there were a website with some reviews and a listing of top providers that would give me a sense of what to expect... (Okay, this is a shameless plug, since that's what ChoiceVendor does.)

• Office Interactive: "All you need to run your business using one system". That scares me; I don't want to run my whole business on this. NEXT.
• BatchBook: "Your Social CRM". I don't really want my CRM to be social. I want it to be efficient. This seems to be about within-company contact management, not CRM (remember, that would be CUSTOMER relationship management).
• Relenta: "Can your email do this?" Again, seems more salesforce / lead tracking-focused.

Let's try investigating "Customer Support Software for small business".

• Business.com -- ooh, that looks promising, they have a result in Google for "Small Business CRM Software: Customer Service Solutions | Business.com" (and I'm not going to link to it because I don't want to make them even more credible for their stupid site). Oh right. Business.com is a crappy AdWords linkfarm.
• WorkEtc: Okay, again they want to manage my entire company. First, dont' want that, second, not authorized to make that decision, third, we're generally pretty happy with Google Apps. (Most of us worked at Google after all, and we're pretty used to their stuff.) However, maybe their Help Desk Software is what I want.

Why are there SO MANY crappy sites for small businesses, by the way?

Okay, now I'm back to Salesforce Service Cloud 2. I can't really see if it does what I need since I have to register to walk through their product demo. Annoying. I'm pretty sure I even have an account with them already, but I'm not going to bother to look it up just to see if they even remotely have what I need.

Open source help ticket system:

Kill me now. I don't want this attached to our bug tracking and I care about the interface and how fast it'll let me get through the emails in our queue. I don't want to have to install anything anywhere, either. Back to paid / hosted services....

Searching through the Thunderbird extensions for business, CRM, helpdesk, and related keywords yielded no results.

Okay, I'm hosed; I've now spent about 2 hours researching this and haven't come up with a satisfactory discussion or solution, so it's time for me to ditch the effort and just process the emails manually.

Le sigh.

Recalling CMU intro HCI course whose capstone project was UI improvements for the PalmOS....

Here's the question on Quora, but haven't yet gotten much of a response:
http://www.quora.com/q/What_are_the_best_fresh_up_to_date_academic_type_resources_for_mobile_UI_UX_design

Jon Kolko, who I met at CMU, just published his book Thoughts on Interaction Design. I'm a guest author and wrote a chapter called "Getting Design Done".

The book's website is http://www.thoughtsoninteraction.com/.

http://www.nytimes.com/2007/03/25/business/yourmoney/25Proto.html?_r=1&oref=slogin

Summary: Let advanced users hack on your products. They will come up with innovations that you didn't think of.

This stands up nicely to an economic interpretation too: If someone is willing to take the time to hack around and build something that wasn't part of the spec, that means that they're willing to spend capital to have that functionality. Which means it's some sort of market opportunity.

Enterprise software can often be maddening like this: companies sell their software for $200k + and they want to be gatekeepers and prevent customers from getting into the code -- they want to preserve the mystique or something. But often they just end up being roadblocks to customer happiness. Like, I bet if we could have hacked on Oracle Calendar rather than having to build our own totally separate version, we'd be vastly more advanced than either system ends up being. Good, complex software takes time (a lot of time) and figuring out how to build on the accumulated knowledge of others (represented in code)

Unfortunately, the article puts this technique in opposition to "traditional" anthropological design processes -- which often aren't well-integrated anyway. There's absolutely no reason why you can't derive benefit from both techniques.

The other day we launched the Google Base Store Connector.

The progression to the final version was pretty neat. When I started working on the project there was a functional demo that had already been built, wizard-style. I came up with a few user scenarios that led to functions like storing account information so users can easily update their items in one click. That is, if someone has an Ebay store and they want to get listed on Google, it'll be better for them if they can store account information so all they have to do is periodically click something to say "okay, update my items" rather than having to re-enter account information each time.

(Yes, there would be faster and more humane ways to do this that don't involve an intermediary application, but those are outside of technical scope.)

The engineers and PMs on the project did an awesome job getting the details right. For example, based on the store you select (eBay versus Amazon, for example) the textual labels change next to the input fields. We used the language from each of the source sites: Amazon uses the terminology "sign in" with your "email address" instead of something like "log in" with your "username" or "user id". Yahoo! has a "Yahoo! ID". This keeps it just a little bit more familar for users. They probably couldn't tell you if Yahoo! calls it an "id", a "user id", or your "yahoo signin", but seeing the same verbiage will trigger subconscious memory and feel a little more "right". Cognitive priming, anyone?

So: a very small piece of software, but reviews on Ebay's forums generally commented on how simple it was to use. Yay! We wouldn't have gotten there without a comittment to good technology from the PMs and engineers. Good user experience is only partly UI design; a lot has to do with the engineering behind the interface.

When it comes to discussions about writing software specs, I really like to quote Sen-Rikyu, the master of the modern Japanese tea ceremony: "Tea is naught but this. First you make the water boil. Then infuse the tea. Then you drink it properly. That is all you need to know." But if you know anything about the actual practice of the tea ceremony, there is -- for laypeople who have not mastered the Zen of simply boiling the water and infusing the tea -- an immensely complex protocool, replete with symbolism that must be adhered to.

Writing specs is simple. All you do is document what has been decided and capture known uncertainties, and underlie everything with a giant disclaimer that until the code is written you won't know exactly how it's going to work.

In fact, perhaps we shouldn't think of specs as specifications of software. They are specifications of goals for the software.

I'm about to start working on a UI spec for some upcoming changes to the Google Base UI. I'm always looking to improve, and this is a pretty complex series of workflows that we have to get just right. So I want to make sure that I capture and communicate all of the decision points that I've traversed up until now, and that I specify behavior that may not be fully obvious in the prototype that I built.

Let me highlight some key concepts from that last paragraph: Capture. Communicate. Spell out corner cases.

So I searched for write UI specs. The first result is 37 signals explaining why specs don't work. I read this type of article -- along with some Agile and XP techniques -- as a radical overreaction to the other extreme (of overplanning and presuming you can actually precisely specify software on a piece of paper before anything is written). In that sense, the 37 signals article is irresponsible. It's speaking to a particular historical context of software engineering without acknowledging that there are a lot of ways that specs can be written, usefully, in the context of more modern software engineering practices. Moreover, when you're not working at a small startup, it is irresponsible to not write specs. Specs help other teams anticipate and plan for what's happening down the line, and when you don't have the same 10 people doing everything -- when you have a marketing department, a customer service team, writers who have to do help documentation -- you need to let them know as early as possible what you think is coming down the pipe, so they have maximum time to plan their own resources and schedules.

Sitting down with my architect this weekend to make decisions about kitchen cabinets, countertops, sink, and how the stairs will work. The kitchen will be monolithic charcoal gray (or maybe white) so it doesn't compete too much with the brick & timber in my loft. Work will start ASAP.

I can't wait to start cooking again. My 14 boxes of kitchen and dinnerware are starting to annoy me, and I want to have dinner parties again.

Pironimo.net is a twiki installation that I deployed, customized, and maintain for a small community of friends (around 30 people). It began on another server in September 2002. Since then I've done about three major UI revs and one software upgrade.

At work we have a bunch of Toto washlets. One day I was explaining to some friends about the wall-attached remote control. One of them, in annoyed puzzlement, asked why on earth would you need a remote-controlled bidet control? This sketch is an exploration of different solutions based on my task analysis.