Showing posts with label usability. Show all posts
Showing posts with label usability. Show all posts

MetaBlog: making the case for blog-through-the-mail

No comments:
ScribeFire has turned out to be quite unreliable, at least for long term storage of notes. At work I left my computer on for about 10 days, with Firefox (and Scribefire) open. When I came back, a memory leak (I think) had rendered the computer unstable and I had to force quite Firefox, and reboot the machine. When it came back up, Scribefire informed me that my notes file had become "corrupted".

Not good. I had a lot of work stored in those notes - mainly research, links, and a rather large idea bin.

There are other problems with Scribefire, such as it's inability to consume the Tab key for increasing indent (a problem which just recently arose). This is a critical problem for someone like me that uses nested lists alot.

I've come to a few realizations, in no particular order: Blogging through email is the key. This allows you to store 3 copies of your work, even in draft: a local copy, a draft copy on the email server, and a draft copy on your blog. Now that's a backup strategy. In addition, if you have multiple blogs, keeping track of where you're blogging to can be tricky - Scribefire was never very good at keeping all that straight. Finally, a single source of posts is easily searchable, and that's quite nice. Some difficulties that arise include tagging (some blogs are better than others - I still haven't found a way to indicate categories or tags in a blogger email). But of course a huge benefit is that the data remains in easily re-published form - you could publish your work to a different location if need be.)

On occasion you may want to post through the web or even with a tool like Ecto or Scribefire. The solution here is to funnel the post back into your email, with email notifications.

Now, this is all well and good, but Scribefire has a few really compelling features worth emulating - browser embedding foremost among them. An email client with strong composition tools embedded in the browser? What exists? A search reveals "not much".

Another feature that I would like to see in Scribefire is a "post to multiple blogs". This feature would either publish a copy to many blogs (not optimal) or publish to one, then publish a link to the others. This would be handy for those "globally interesting" entries that also have more specific applicability.

Vista vs. OS X Leopard

No comments:
I've had a bit of a wild ride this last week on my quest to find a good computer with 4G (or more) of usable RAM, and a better CPU, primarily for software/web development. (Eclipse + FF + MySQL + everything else is a bit of a hog.)

My first thought was to go with Vista 64-bit running on a quad-core speedy machine. The first machine was very fast, but very big and noisy, so it went back almost immediately. The second machine was a very nicely made Gateway machine running Vista Home Ultimate 64 bit edition. The machine was good enough that I was able to keep it long enough to realize how bad Vista really is.

The key problems with Vista were very poor driver support, very poor application support, and file manager and system preferences that are impossible to navigate and butt ugly. And then the sheer sum of minor niggles was very long - UI elements were moved apparently at random, and most menu bars were removed. Many of my utilities from XP wouldn't run. I spent some time trying to address these issues individually, but in the end I gave up, mainly because I knew it didn't have to be this hard.

It's true that I could have installed Linux (probably Ubuntu) on this machine and been happy. But then I realized how crazy the whole idea of moving to a desktop was (I like to move around too much), and how important usability was, and how there's a little company in Cupertino who makes products for people like me called Apple Computer.

And you know what? I bought one (white MacBook 2.1GHz 1G 120G Penryn, home-upgraded to 4G, 200G 7200RPM). And I'm quite happy so far. The system is pretty and quiet and unobtrusive (very different than most PCs! Even the Thinkpad, by far my favorite PC, has a rather muscular, angular look in comparison). But what is really a breath of fresh air is the OS, OS X Leopard. I've come to understand why we pay people to improve the usability of software products - they earn their money, many times over, both literally and, I would like to think, spiritually. I mean, after all, isn't it nice to create things that leave people feeling happier, or, at the very least, no worse off than when they started using the product?

I think the key ingredient to Apple's success is simply this: they got the drivers right. To have a relatively stable platform to develop for has got to be wonderful. As any web developer knows, it is a sheer delight to write an app that only has to run on a single, modern browser (that isn't IE). I am sure that the same holds true for operating system programmers. One can really optimize the experience when you know approximately what hardware the user has to work with. And this frees programmers and UI people to do what they do best: a strange combination of "thinking outside the box" and obsessing over details that yields beautiful, functional software.

There are several simple things that Apple gets right with OS X. For example, the whole "disk image" thing, or dmg, for installing software is really sweet. The Windows notion of treating zip files as psuedo folders (introduced in XP SP1, I think) is brain dead in comparison. Having a real command line is huge for programmers (and end users benefit too because a happy programmer makes happy programs). I can't tell you how glad I am to get past Cygwin - not that Cygwin itself was bad (it's been too useful for me to call it that), but that terrible terminal and the file system skew drove me batty.

What's really interesting (and wonderful) is the sheer lack of things I have to install. For example, I no longer have to install ctrl2caps because you can remap the caps lock key using built-in and easy to use system preference dialogues. I've not had to install a firewall, anti virus (although I may install that), spyware blocker, or any of those sysinternals utilities designed to help make up for and recover from Window's deficiencies (although I have to add that a process explorer equivalent would go nicely). I don't have to install any "helper" software for multi-display or network setup (e.g. the Thinkvantage utilities that come with the Thinkpad) - the built in stuff works about 10x better anyway.

Then there are the pile of peripherals I don't need to buy or configure. Wifi is built in of course, but so is bluetooth and a webcam - and the last two are far from common on PCs. I won't need a firewire adapter if I get into video. And there are a bunch of utilities I don't need, like CD burning software because the Mac software just works. I don't need to install a better Explorer because Finder works. I may not install Thunderbird because Mail works (well, a lot better than Outlook anyway). I don't need DVD playing software because the Mac utility just works. (And I can't say the same for the Windows equivalents).

That is not to say the Mac is not without it's issues. Some sort of media reader would make a lot of sense (particularly an SD card slot). But more seriously, the way the mouse moves needs to be more adjustable. I'm used to a very linear mouse response curve, and the Mac seems to demand that you use a lot of acceleration - I do hope to find a solution for this as my hand is already aching. It would be nice to have some sort of docking port for the Mac, so that the tangle of cords (well, the power and external monitor cord, anyway) would be both hidden and easy to (re)connect. A second mouse button on the laptop itself would be greatly appreciated. I would like an easier way to move windows around, along the lines of the (sadly buggy) NiftyWindows for Windows. And there are some Windows things, like the excellent Fiddler debugging proxy and SQLyog, that I know I'll have to run in a VM (I hear Parallels is good), if at all.


jQuery on a CDN - finally

No comments:
Google was kind enough to host jQuery on a CDN (they also have prototype, mootools, dojo and a few others). While they have a fancy loader script that offers conveniences like optional minification, you can also get the script the "old fashioned way", with something like this:

http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js

In truth jQuery just isn't that big (about 15kb) so this isn't really useful for saving bandwidth - it's more useful for improving first-time user usability by reducing their wait time by maximizing simultaneous downloads. Most modern browsers are limited to two connections to a given server, and so spreading the load across many servers is a Good Thing. I'm not sure if this limit has a name, or even an RFC. I do know that the limitation is designed to prevent unintentional DOS attacks.

While I don't see anything particularly nefarious about this, I would like to point out that Google and the Mozilla Foundation (who employ John Resig, author of jQuery) are extraordinarily friendly, and I'm glad Google is performing this service.

RifleThru: A good use of GWT

No comments:
RifleThru - an improved ebay search application, written in GWT over Apache AxKit. It shows good use of GWT for usable design, and a very light-wieght, non-Java backend used to convert eBay's XML API into JSON.

Even the big boys get it wrong...

No comments:
MSN's homepage has some serious problems today (FireFox 2 for Windows):


The problem with wikis

No comments:
Wikis seem to go stale really fast. I know this because I've used internal wikis at every company I've worked for or with in the last 8 years, and in each case the wiki was never an important part of anything. (Indeed, the wiki was often used by managers as a kind of threat - "add it to the wiki" is a way of saying, "please do some meaningless work that will never be read and will be quickly forgotten.")

But all writing on the net gets stale fast. Why does it feel so particularly bad with wikis?

I have a theory. I think it's because wikis set your expectations differently than, say, a blog. You don't expect a blog to stay relevant. Wikis feel static, and you expect them to stay relevant. It's a classic UI problem, actually. In truth, wikis and blogs are both just representations of an author's activities. One is merely presented in a different way. I believe that blogs are actually closer to representing the moment - one has a thought, one writes. Wiki's still subscribe to the conceit that this is an article, something that is correct and timeless and that fell out of the sky. Wikis hide the serial nature of authorship, while blogs do not.

7 usability testing mistakes

1 comment:
From an article on the "user interface engineering" website:
When a design has a usability problem, it's because someone made a wrong decision. They chose to take the design in a direction that creates frustration for the user. A different design choice would have prevented the frustration.

We consider a usability test to be successful when the design team members receive the information they need to make the right decision. Successful usability tests produce informed decisions.

There are two outcomes from poor decisions: either the user experience is worsened because of a change that just shouldn't have happened; or a valuable opportunity is missed to improve the design's user experience. Either way, when usability tests work, these results are significantly less likely.
  1. Not knowing why you're testing
    1. It's not about how the user "feels"
    2. Its about telling where the UI causes frustration.
    3. Pose behavioral questions
    4. "Usability testing is all about seeing the design through the eyes of
      the test participants. As they work their way through the design, you
      get to see and hear what works well and where it becomes frustrating to
      accomplish their goals."
  2. Not bringing the team together
    1. Do the test nearby the team.
    2. Video the test
  3. Not recruiting the right participants
    1. Don't focus on demographic (age, income)
    2. Do foxus on distinctions that make users behave differently (fluency in the content area).
    3. If they don't have the right experience, they'll get stuck in places where the real users will breeze past.
    4. "What attributes will cause one user to behave differently than another?"
  4. Not designing the right tasks
    1. Users want to please you by following directions, so make it a bit more freeform.
    2. "You can get around this mistake by constantly exploring the "context of
      use." When designing tasks, ask yourself, "What events or conditions in
      the world would motivate someone to use this design?"
  5. Not facilitating the test correctly.
    1. Not boring for participants or team members
  6. Not planning on sharing the results
    1. Get the info to the design team
    2. Reports don't work very well - they don't get read
    3. Instead use "review sessions that happen right after each test, starting an email
      discussion list to talk about the test and various interpretations, and
      interactive workshops to review the design and what we learned"
  7. Not iterating to test potential solutions
    1. "Usability Testing is great for identifying problems. Yet, it's horrible at identifying solutions."
    2. "we've never run into a design team that couldn't generate a half dozen
      possible solutions to any problem, within moments of its discovery."
    3. "Plan a round of testing, to validate any yet-to-be-discovered potential solutions."