Jumping In

In a rather accidental manner, I am starting up several new projects. I am really getting into Wiki’s. I installed MediaWiki at work for internal collaboration and knowledge management. I decided to run it on Linux instead of Windows, so I installed Ubuntu. Wow! First time I have ever done anything with a *nix. It’s fantastic. I am considering switching my home machine to Ubuntu as well.

I have made many ASP-based web sites before, but now that I had a Linux server, I thought I’d try something different. I installed Django, mainly because I have always wanted an excuse to learn Python. It was much easier to get going than ASP. I had heard the same thing about Ruby On Rails for a while, but had my doubts. Those doubts are gone.

My biggest problem now is finding the time to explore them all.

Hello XUL Runner

I have been playing with XUL Runner. It feels like writing a web app, but runs on the desktop. Windows, Linux and Mac desktops. Sweet!

Other things I like:

  • Nice selection of widgets and layouts
  • XBL allows new widgets and behavior to be added.
  • XPCOM allows calls to JavaScript and C++ non-GUI code.
  • SVG support is builtin. (soon)

UI Frameworks Are Pigs

Why are UI frameworks pigs? Because they don’t love you back.

You know the story: You meet this new UI framework. It seems so fresh and exciting. You start spending more time together, just doing small stuff. Things are so easy, not forced or boring like with your previous frameworks. So what if it acts a little immature. Before you know it, you’re writing specialized controls from scratch, embedding large amounts of business logic and enjoying every minute of it. You’re head over heels. Next thing you know, you’re crying yourself to sleep and listening to Barry Manilow.

Come on buddy! Snap out of it. UI frameworks don’t love you back. They don’t care about you. You need to watch out for yourself. Protect yourself. Isolate your code.

If your not ready to drop your current UI framework and switch to something else right now because it could take person-years to port, you have problems. If you have team members that love your current UI framework too much to want to change, you have problems.

They don’t love you back.

The experiences above are not about me, but I have this friend…

AJAX and Rocket Science

Seems I am not the only one disturbed by the FUD some groups are pushing about AJAX being very difficult to implement. This post has some good examples of how easy it can be.

Writing good, quality software is non-trivial in any language. Wizards and RAD designers do not automagically generate great software.

Scalable User Experience

John Montgomery on Scalable User Experience. Although I disagree with the rocket scientist required myth, I agree with John’s conclusions. I especially like this quote:

Rather than trying to replace every application model in use today with one perfect model, a better solution is to let them flourish and to connect them together so that each can do what it does best. This vision, which I’d call the “Scalable User Experience,” is where Atlas begins to take application models. This team is building off three tenets (even if they don’t know it):

  • Respect the richness of the client (whatever that is) to provide the best possible user experience
  • Contain complexity on the server to build on existing administration skills and infrastructure
  • Leave no developer behind by using existing developer skills, code, and tools

I believe that AJAX is a methodology which can help achieve scalable user experiences. I am hoping toolkits like ATLAS can help with some of the weaker aspects of web applications, mainly integration with the desktop client.

This Just In: AJAX Is Important

Looks like Microsoft is getting on the AJAX bandwagon, whether they like it or not. Scoble mentions a Microsoft Javascript library named ATLAS. CNET, Microsoft Watch and Information Week posted articles about ATLAS. Charles Fitzgerald is, again, the MS guy involved. Reading the articles, I can’t tell if Fitzgerald is excited about ATLAS/AJAX or just feels like its something MS needed to do to stay relevant in web development. Some quotes:

“People who do (AJAX development) are rocket scientists,” Fitzgerald said. “In some ways, this papers over the mess that is JavaScript development. It’s easy-to-build ‘spaghetti’ code.” [CNET]

“Microsoft is really the only company that spans the continuum, from the simplest Web client through he smartest client,” said Fitzgerald. [Microsoft Watch]

“We just needed the clever name” – like Ajax, Fitzgerald said, to explain the various things that developers have been able to do for almost a decade with Microsoft technologies. [Microsoft Watch]

Using Atlas, developers will be able to write Ajax apps that contain pre-written code to smooth over technical distinctions between Web browsers, and debug those apps with Microsoft-branded tools, says Charles Fitzgerald, a general manager at Microsoft. Using Ajax today, he says, “is a little bit of a hack.” [Information Week]

Here is what I think:

  1. Microsoft invented the technologies now called AJAX, but moved away from browser based clients in favor of Windows based clients (Smart, Rich, Thick, Fat or otherwise).
  2. The world of web development is quickly moving toward AJAX-style development. Microsoft is late and needs to make some mindshare.
  3. Microsoft is a development tool vendor. They sell tools to make development easier, therefore, current AJAX development must be hard (rocket scientists need only apply) and messy.

Seems to me that many AJAX toolkits already exist. Many web applications are incorporating AJAX very quickly. Examples of AJAX range from simple enhancements to full blown applications, implemented by mere mortals.

This move does not seem in sync with Microsoft’s .NET/WebForms/Smart Client agenda. Therefore, I question whether their heart is in the initiative. On the other hand, Microsoft’s new RSS initiative (also connected to Fitzgerald) seems inline with current company agendas and has good backing inside and outside the company.

Update: Scott Isaacs of MSN Spaces and Scott Guthrie of ASP.NET have some good technical posts on AJAX.

In Search Of: A Usable UI

Jeremy Zawodny’s Surprising User Expectations post and Jeff Atwood’s UI is Hard post draw attention to a big problem in software development: Developers rarely design good UI’s. I have come to the conclusion that UI design should be handled by people who understand how users think, interact and model problems. This is more of a human factors problem than a coding problem.

I am a big proponent of making usable software. It’s one of my crusades. Usability is not defined by developers, it is defined by users. We recently completed our second phase of usability testing on a new product. It’s always a learning experience watching regular people trying to use software. It can be frustrating when it’s software I helped to develop. To make better UI’s, developers need to appreciate the obstacles that confront users and try remove the obstacles. Usability testing and reading people like Cooper, Nielsen and Norman can give you a better perspective.

Here are a couple guidelines I compiled from my own experiences and from people smarter than me:

  • Be flexible: Allow for multiple ways to get something done. Use main menus, toolbars, right-click menus, task panes and hyperlinks. This allows the user to choose the way most comfortable to them instead of forcing them to learn your way. Keep in mind that for any given user, the preferred method could change over time.
  • Be explicit: Don’t force the user to guess or explore the UI. Use verbose captions, messages and explanations.
  • Be proactive: Don’t wait until the user gets into trouble, keep the user from getting into trouble in the first place. Why wait until the end of a process to inform the user they made a mistake at the beginning?
  • Be forgiving: Make it possible for a user to recover from an unwanted action. People make wrong choices. Recovering from a bad choice with most of your data intact is far better than being forced to recreate something from scratch.
  • Be simple: Simple, focused screens and dialogs are easier to learn and allow users to get things done faster.
  • Be consistent: Make use of the fact the users can learn how to do things. Don’t force them to re-learn how to do the same or similar things.

None of these points is revolutionary or even original. But it’s amazing how few applications implement them.

Jeff’s post has some good links to other articles that are worth checking out. He also brings up the concept of UI First development. I definitely agree that the UI should be given some focus early in the project. Unless your building an engine or library, the end-user is going to equate the UI with the software. If the UI is bad it won’t matter how good the code is behind the scenes.

Update: For those interested, a co-woker pointed me to another UI First design methodology at Human Factors International (HFI).

Rich UI vs User Experience

John Montgomery and Jon Udell are having a discussion about AJAX and rich internet applications. Montgomery is trying to determine what all the fuss over AJAX is about. He played with some toolkits and is unimpressed. Why? He doesn’t see how AJAX can compete with Winforms/Webforms on user experience. John says:

Mostly, Jon’Â’s posts got me to thinking about why we (that’Â’s you and me -– Web users) are OK with degraded user experiences. I mean, for years we had great desktop applications to do things like calendaring and email and even mapping software. Then came the initial Web, where HTML 3.2 and some JavaScript meant that Web apps just couldn’Â’t be as nice as local apps. And now we’Â’re all very excited about things like Evite, Gmail, and Google maps. But compare Google Maps to Streets and Trips, which I did recently, and the experience with S&T is much better. Same with Outlook vs. Gmail (usually, anyway). Heck, most people read blogs through a Web browser, not an aggregator, even though aggregators are much more efficient.

So why do we let ourselves settle?

I think he is confusing user experience for rich widgets. Web-based applications can achieve a high level of user experience and usability without the need for complex widgets. Good web applications are simple, small and well focused to the task at hand. In fact, I always use the web versions of the applications he lists over the desktop versions.

As John points out, the web-style hyperlink approach, with few options and everything laid out in front of the user, is easy to learn and use. To me, this increases user experience, not degrade it. John also points out that content is more plentiful in web-based applications and users like getting content. So much so that he feels users are willing to give up a great UI if they can get great content. Why does a user want a great UI at all? Seems to me that users only really care about content (or data). I think usability experts like Nielsen and Cooper would say a great UI is a UI that allows users to complete tasks without getting in the way. The UI should not be centerstage.

Udell’s posts point out that AJAX systems have a tendency to allow users access to content they want in ways the web-UI did not anticipate. Also seeming to confirm my suspicion that users don’t care much for flashy UI’s, but graviate to applications that make it easy to extract and manipulate content. WebDAV and SOAP are not low-hurdle technologies, XmlHttpRequest seems to be. AJAX is a methodology for enhancing web application functionality, not for replicating desktop applications. People don’t want desktop applications running in the browser, didn’t Java teach us that?

XML File Formats in Office 12

Brian Jones, program manager on the Word team posted news about the new XML file formats in Office 12. I have posted a few times on XML file formats, so I am interested in what Office is doing. Some interesting points:

  • Full fidelity. As good as the binary format.
  • Compressed. Lots of file parts stored in a structured ZIP archive, similar to OpenDocument
  • Fully documented. Whitepapers, documentation and XSD schemas.
  • Robust. A lot less likely to get a corrupt file that can’t have pieces recovered.

IMO, the above points could be true for any product using an XML package format, but the fact that Office is doing it means millions of users can escape the data roach motel.

Scoble has more on Channel 9 as well as his own blog. Jones plans to link to whitepapers as soon as they become available on MSDN.

Granted, Office is following OpenDocument here, but this is a really good thing.