Wednesday, May 30, 2007

The Low-Down On Low-Fidelity Prototyping

(I had a lot of time sitting around the airport after ILUG, so I wrote another of my dissertations...lucky you...hehe ;-)

You don't have to be on this site for very long before you'll start picking out some common themes. Two of the topics that I am very passionate about when it comes to the development process are low-fidelity prototyping and usability testing. I truly believe that every developer (no matter what their preferred technology) can reap enormous benefits by adding these two simple techniques to their development methodology.

On the most recent Taking Notes podcast, I mentioned I have some articles about usability testing coming up. Well I do, but I thought it might be a good idea to cover the first of my two 'secret weapons', since usability testing actually follows as a logical extension of low-fidelity prototyping. With that, let's first define what low-fidelity prototyping is about. Due to its RAD nature, most Notes developers are very familiar with the concept of prototyping. In the case of low-fidelity prototyping, the word 'fidelity' refers to the level of detail in the design itself. That is:

Low-Fidelity = Quick & dirty hand drawn screens

High-Fidelity = Polished design or high-quality screenshots/mockups

Another name for low-fidelity prototyping is "paper prototyping" and perhaps this name more fittingly describes what you use in the process. I prefer low-fidelity prototyping because it sounds more impressive, and if I were a consultant, I could probably charge more (haha...OK...only kidding!). The purpose of the low-fidelity prototype is to allow you to design the interface of your application before you focus on anything else. Some developers think I am committing heresy when I say this, but I believe without a doubt that you can design a better application if you build the interface before you write any code!

One of the first benefits that low-fi prototyping brings you is the ability to talk to a customer in concrete terms very early on in the project. When they are giving you requirements, customers usually have very nebulous ideas about what they are actually looking for or what they are going to get. It is very powerful to be able to return to the customer shortly after the initial meeting with a physical object that they can review, manipulate (by turning pages), etc. This initial prototype may be completely wrong, but it gives you a common platform from which you can continue your discussions about the application. I think you'll be surprised at what additional information you uncover so early on. There are several other benefits that low-fidelity prototyping brings to the design process, but first let's take a step back and talk a bit about how you build one.

Perhaps one of the neatest things about low-fi prototyping (that's what the cool kids call it) is that it is so easy to do...and dare I say...a lot of fun. The tools of low-fidelity prototyping are all those things you used in kindergarten; paper, pencil, markers, crayons, scissors, glue sticks, etc. The key to low-fidelity prototyping is drawing out enough detail to allow the customer to figure out what is going on, but no more. The low-fidelity prototype is not meant to be polished. It's just a 'rough draft' of your screens. A lot of great work in design and engineering was initially conceived on the 'back of an envelope' and the concept is the same here.

To get the most benefit from this technique, you need to draw out all of your interface elements. This includes screens, menu items, dialog boxes, etc. Place only one element on a page (e.g. if you have 5 dialog boxes, use 5 sheets of paper, one for each dialog). This makes it easier to manage your design, especially as you work through multiple iterations. That's really all there is to it!

As you are beginning the work on your low-fi design, remember that this is the ideal time to 'think outside the box'. Try to forget the constraints of your development platform and instead focus on how you can design an interface that will be clean, efficient and easy to use. If you have the luxury, I think the ideal state is to stay technology agnostic. Design the interface, figure out what functionality is needed and then decide on which tool is the right one for the job. You can temper this with good judgment, of course. If you know you are building an application in Notes, don't design an element that you absolutely know you can't use in the client. However, some of the best interfaces I've made were initially born out of low-fidelity prototyping, followed by an exclamation of "There's no friggin' way I can do that!" A little perseverance and a lot of experimenting in this regard can pay off big time, though, so give it a try. The worst that can happen is that you fail, learn a lot from that, and then move on to plan B.

Once you have completed your first low-fi iteration, schedule some time with your customers to discuss it. See if they can understand the functionality without you explaining it to them. Are there glaring errors that are immediately evident or are they just bringing up subtle points? Make sure to take as many notes as possible, trying to capture everything the user points out or alludes to. You can often find important information in these notes...things the customer initially forgot to tell you, details on how computer savvy the user base is, etc.

So...You've built your prototype, met with your customers and got a couple of suggestions for changes. Time to go write some code, right?! Whoa, there partner...not quite yet. Unless you absolutely nailed it on the first try (probably not), it's time to build another iteration. On average, I'd say you'll build about three low-fi designs in a typical project. Each time, you'll refine and meet with your customer, coming closer to the final interface with each pass.

Let's return to discussing benefits around low-fi prototyping, since this is one of the stages where you really see a payoff. One reason low-fidelity prototyping works so well is due to the psychology of how we perceive quality. A user looking at an actual application on the screen is generally less apt to point out flaws, even if you only invested a little time in it. They think to themselves, "Gosh, he's already got something ready for me. I guess I can live with this, even though it's not exactly what I want." The customers tend to censor themselves, since they think you've invested time and money in the design. At this point, you might be thinking "Not my users...they hate everything and tell me so!", but most people will do this, just to varying degrees. Users generally have no problems, however, when you throw a hastily drawn piece of paper in front of them. When it looks like you had a little kid whip something together, the customer will definitely let you know what they think! :-) In fact, I suggest a little experiment. When you go into your low-fi meeting, strategically place some pens, pencils, crayons, whatever, in an area that the customer can readily access. I'll bet that when you set the prototype in front of them, they reach for one of those implements and start marking away. Let them! This is valuable, as it helps you see what they really want. It also gets the user emotionally invested in the design, which in my experience leads to increased satisfaction at the end of the project.

As developers, we benefit from low-fidelity prototyping as well. It may sound like this process adds time up-front and you're does. However, once your prototype is pretty well finished, you've got a great plan for development. You won't be sitting there staring at a blank canvas, wondering how to start. Instead, the low-fidelity prototype provides great clarity and allows you to concentrate on the next important part of your process, actually writing the code. Also, since we've avoided code until this point, we've probably saved time and money. Often, the choice of interface elements we use dictates the most efficient path we take coding wise. Any time you start development by writing code puts you in danger of having to back track or rewrite in order to address UI concerns. Hopefully, you can see that capturing the specifics of the UI up-front helps mitigate these risks.

The definition, increased communication and clarity that low-fidelity prototyping can bring to a process is highly beneficial by itself, but it becomes infinitely more powerful when combined with our second 'secret weapon', usability testing. That's can actually test your application using the paper prototype (how cool is that?) We'll explore this technique in a future post.

For now, let me leave you with a call to action. Give this process a try on your next project. It's certainly not hard and I think you'll find it very powerful. If your customers (or most likely your boss) look at you a little weird, be honest with them. Explain why you are doing this and the possible benefits (hint when dealing with the PHB* --> "It saves money!!!"). Let them know that it is a new concept for you as well and that you'll learn together. The customers will appreciate your openness and will most likely be willing to give it a go. My guess is that after the project, you'll be doing a lot more low-fi work.

Overall, low-fidelity prototyping is a super technique that I use all the time. I hope you find it as compelling as I do. Good luck!


Monday, May 28, 2007

RSS Feeds For Notes Documents

(Editor's Note: This tip was initially published on SearchDomino and was a Hall of Fame Tip of the Month winner. It was modified slightly to address new links, etc.)

Many Lotus Notes developers have started adding the construction of RSS feeds to their repertoire. There are already many great resources on how to do this available on the Internet, so that won't be covered here.

Using whatever method you choose to generate your RSS, you can present an RSS feed to documents stored in a Lotus Notes database. Usually, RSS feeds point to content that is accessed via a web browser. However, I had the need to pull up the documents in the Notes client instead. This is very easy to do, since you can use the Notes URI format in place of the standard HTTP URI.

Here is a snippet of XML code from a feed that demonstrates this:

<title>Spellcheck the Memo Body Only</title>
<pubDate>Thu, 24 Feb 2005 10:39:25 PM -0400</pubDate>
<description>I posted this R4.x tip to SearchDomino way back in 1999 and it was the winner for one month!</description>

Notice the <link> element references a Notes identifier rather than a URI using HTTP. When users view this feed in their RSS aggregator, it will open the proper document in your Notes client.

The <link> element of your feed can be constructed using the following formula (usually calculated in the document or in the view column):

"<link>notes:///" + @ReplaceSubstring(@ReplicaID; ":"; "") + "/AllDocuments/" +
@Text(@DocumentUniqueID) + "</link>"

You can replace "AllDocuments" with the name of your view or use its design ID.

For an "All Notes" experience, you can use a Notes-based aggregator such as Steve Castledine's ProjectDX Feed Reader or Studio Blog Reader from OpenNTF along with your feed.

This is a simple yet powerful way to increase the value of using RSS within your organization. I hope you find it useful.

ILUG 2007 Recap's 10 PM here in Dublin on Saturday night and I am sitting in the lobby thinking back over the crazy last few days. ILUG 2007 has truly been an amazing experience and one of the best conferences I have ever attended. The entire ILUG staff (Paul, Eileen, Kitty, Tom, Bill and Warren) are to be commended for a job very well done. From the looks on the faces of the attendees as they exited the closing session Friday afternoon, I think the conference was a resounding success. I have to thank the ILUG team for the opportunity to present my little session. It was truly an honor and a privilage to come to Dublin and speak to the attendees. I met a lot of great people and I look forward to chances to meet again in the future.

I always feel like the dummy in the group when I'm looking over the speaker list and I'm still amazed I'm even up there. It's really energizing, though, when people tell me how they've been inspired by my techniques (or even better...they show me a db where they are trying them out)!!! I started this blog because I like to write and I like to teach, so I thought it would be a good outlet for those interests. That it has translated into the opportunity to get up on stage and speak about this topic I'm passionate about with the community that I love so much is really special and I thank everyone who showed up for giving me the opportunity!

As for the conference itself, it was just amazing from start to finish. Alan and Mary Beth kicked off the show with an inspring look at IBM's strategy and with some of the ideas about decisions for Notes 8 and how they were made. From there, the sessions started. The technical content was brilliant and indeed we were very lucky to have the opportunity to see this stuff...AND FOR FREE!!! Tom Duff got the ball rolling with an introductory AJAX session that set the stage for a couple of other AJAX sessions later in the show. The technical level was perfect for the beginner and Tom has a great, relaxed delivery style that's fun to watch. While Duff got the "jazzed up on caffine after coffee break" crowd, I was up after lunch. I was afraid I was going to send everyone into the post-lunch food coma much quicker than normal, but we had a packed room and I didn't see anyone nod off. It must have been the dancing nuns! ;-) Bruce, Vince and Kevin were giving an OpenNTF presentation next door and were able to successfully throw me off with a rousing cheer of "Hi Chris!" from the room next door. I decided I couldn't even try to compete with that, and after frantically trying to remember what I was talking about, we got back on track. I had a great time...thanks if you came by!

Other excellent sessions I attended included Rob McDonagh and Bruce's OpenLog talk, Deborah Latter's decision-making presentation (complete with ringmaster costume and real bull whip!), Sean Burgess' Domino blogging template overview, and Grégory Engels' "Pimp My App With Ajax". Last but not least, the man who went the farthest to buy the delegate love...Mr. Rob Novak's Free Code and Beer session, where he placed an order for 80 pints of Guiness(!) to be delivered and enjoyed while we watched him and his Ajax code magic. You all did a spectacular job! The only bummer was the fact that I couldn't get to the other equally deserving (and I'm sure just as excellent) presentations that were going on at the same time.

Speedgeeking was a blast! I've never had to talk so fast and so much in such a short time, but everyone seemed to love it. The open bar from IBM probably helped here too! :-) I presented 5 techniques with layers staring Shrek and the gang ('cause onions have layers, ogres have layers and Notes has layers!). If you are looking for the sample database, I have to get it ready for download...keep an eye out in the next couple of days. Rocky did a great job as MC. I hope I have the chance to participate in Speedgeeking again sometime soon.

Thank you also goes to the sponsers and ILUG team for all of the off hour events, such as the drinks reception, Geek Dinner and so on. The Geek Trip was a perfect way to wind down the event, although it looked like most of the people on the bus were ready to collapse due to lack of sleep! :-) It was very nice to meet so many of the delegates to the conference as well. Thanks for saying hello.

Finally, to Mr. Bruce Elgort, my hat is off to you sir. You truly are THE MAN!

Now just a few days rest and it's off to Boston for Lotus Developer2007. Whew!

Tuesday, May 22, 2007

Press 'Enter' In A Field And Trigger An Action

(One final post before I head off for ILUG2007 just because I love you guys! :-)

For all of it's usefulness, the signal-to-noise ratio on the forum at Lotus developerWorks (i.e. is quite low. When you do find a really useful nugget, though, you want to share it with the world. I found just such a nugget, which is related to my blog topic from the other day.

If you remember, on the homescreen of my application is a field that allows the user to enter a number and immediately get to the applicable document. I wanted to allow the user to not only use the hotspot to trigger the action, but also to be able to just hit enter and have the action execute and open the document. Unfortunately, I've never found an acceptable solution to this in the client...until now. So, for further proof that there are waaaay smarter folks out there than me, check out this innovative use of JavaScript in the client to accomplish this feat (thanks to Peter Smith!!!):


Then come back...I'll wait...

Tres chic!

So what's going on here? The Reader's Digest version is that when the user enters the search field, the JavaScript function runSearch is triggered and every 1/10 of a second checks the value of the field. If it encounters a press of the 'Enter' key [ if (sString.indexOf(newline)>=0) ], then it clears the newline and presses the button to trigger whatever action you've setup. my case, I changed the hotspot link to a button. The button contains the LotusScript that does all the work of finding the document and displaying it to the user. Then I simply placed Peter's code in the places he notes in the posting above, and et voilà! Now the user can click the button or hit enter. A simple and elegant solution to a problem I never had solved before.

One tip. If you use an OS-style field, make sure you 'Allow multiple lines' for the field. If you don't, pressing the 'Enter' key won't generate a newline and the JavaScript will never execute the button press.

One other thing you might consider is to clear out the field when the user executes the search. This will depend on your situation, but in my case, the last thing the LotusScript in the button does is clear the field. That way, if the user returns to the homepage by closing the document window, the field will be ready for them to enter the next number.

Friday, May 18, 2007

Sample Database: Collapsing An Embedded View

A couple of weeks ago couple of months ago (wow...time is flying!), I wrote up a little post about collapsing a categorized embedded view. It got some interesting responses and also generated a bunch of questions and some calls for a sample database. I finally had a few minutes to put a sample together, so this post is to point you to that (I actually used my 'Cool Docs' database since it was easy to update). Hopefully this may shed some light on any problems you had getting this to work.

You can get the database here.

To test it out, compose a new document with either the "Collapse Embedded View Example" form or the "Collapse Embedded Single Category Example" form.

Don't Forget! When you are testing this in the client, make sure you close the form in design mode. If you don't, the embedded view will continue to stay open and the collapse will never work.

If you have any problems with the sample database, you know where to find me. Have a great weekend everyone!

Do The Heavy Lifting For Them...

Every time you design some new functionality for an application, you have the opportunity to delight your users by focusing on making the task easier or you can frustrate them by making things more difficult. Obviously, most of us want to achieve the former, but sometimes in our rush to simplify OUR lives (shorter development time, easier maintenance, etc.), we tend to gravitate toward the latter. Especially when we are building something that we've done 100 times before, our inspiration may be low and it's difficult to overcome the inertia of "let's just get this finished as fast as possible". One way I've found that helps me overcome this feeling is to take a step back and look at the functionality through the eyes of the user. I try to imagine what scenarios might be playing through the user's head as they sit down and see the screen I've designed. Is the layout clean and simple? Are elements labeled appropriately or is the form laid out in such a way that the purpose of each element is intuitive? Does the new functionality I've just designed make their lives easier or do they need to exert more effort to get what they want. In other words, am I doing the heavy lifting or are they?

The answers to these questions can sometimes be very enlightening and can help you frame the context of your work in a more user-friendly way. Here's a recent example from my own experience:

I'm putting the finishing touches on a simple workflow application. It actually has a few neat and unique features, but most of it is the standard stuff. It happens to be a sister process to another application that is already in production, so it made sense to design the look and feel of the app to match the existing one. All of this makes for fairly tedious design work. Once most of the application was complete, I took a step back to review some of the functionality. One of the first things that struck me was that I had a really great feature on the main screen but I fell into the trap of making the user do the heavy lifting.

Sticking with my common theme of getting the user to their data as quickly as possible, I have a data entry field on the main screen that allows the user to input the unique identifier for the document, which takes them right to the form in question (assuming it's found).

For this particular application, documents are numbered according to the last two digits of the current year, followed by a "-" and then a three-digit sequential number (e.g 07-006). In my initial incarnation of this functionality, I just took the value the user entered into this field and did a lookup by key. If I found a match, I opened the doc, otherwise I told them there was no such document in the database. After spending a little time reflecting on this, I did some research into how users actually use these numbers. When communicating about a particular EWR, did they say "O seven dash O O six" or just "six"?

Turns out (not surprisingly) that there's a lot of variation about how people remember these numbers and communicate about them. This fact made me go back and rethink how to write the code so that it would simplify the act of finding a document for most of the users. With just a little extra effort, I was able to modify the code so that users can type in a variety of different formats and the document will be found. Using the example above, they can now type in:


If the user leaves off the year designation, then I assume it's the current year. They can choose to enter just the significant digits of the EWR number and in the code I simply manipulate the string they enter to use as my key in the lookup. I even check for ambiguous entries, so if they enter something like "06-", I then bring up a dialog box showing all of the 06-xxx documents. Overall, I tried to address the main ways a user might enter a number so I don't have to bring up a nasty error message telling them their document couldn't be found. I know it's really frustrating for me when I use an application and I am sure something is out there, but I just don't have the correct syntax to find it. It's empathizing with this frustration that inspired me to go back and work on the lookup functionality. Fairly trivial? Yes, it is, but add up the small gains like this and you end up with a much better user experience. With the new functionality, the user doesn't have to spend time thinking "what is the format I need to use to find a document?". Instead, they can just enter the number in the format that they are used to and they'll be whisked away to the document.

I encourage you to try this the next time you are building something new or tweaking an existing design. Try to find those places where you are asking the users to do more work than is necessary and then use your skills to make it easier for them. After all, as the developer, you've got all the muscle.

Monday, May 14, 2007

Enhancing Productivity With Links

Hi All. I hope all the moms out there had a nice Mother's Day. Now it's back to work, though, so it's time for another post. This is a simple one today, to kind of ease into things after the relaxing weekend! :-)

It seems there are a lot of people who know about .NDL files and an equal number that don't. If you haven't created or used an NDL before, read on. If you have, you might want to skip to the bottom and see a really cool way to use them.

Creating an NDL

An NDL file is basically a document, view or database link that can reside out in your file system. It is represented by a Notes icon and when clicked will open the corresponding element. It will probably make more sense to you if you see it in action, so try the following steps:

1. Create a link to the view, document or database of your choice in the standard way (e.g. Edit - Copy As Link - View Link).

2. Open Notepad (or your favorite text editor) and paste into the body of the new document. You should see some XML looking stuff, which is how Notes represents a link.

3. Save this file, giving it any name you choose (a descriptive name such as "Tasks By User View" is best) and using .ndl as the file extension.

Take a look at the location in which you saved the link. You should see the icon for the file you just created.

Now double-click the link and check out what happens. Takes you right to the element in question. Pretty cool!

Uses for NDLs

NDLs can have many uses, but I would imagine the primary reason most NDLs are created is to send links to users in other mail systems. I know in the past that the Exchange Connector used them and of course CoexLinks does this too. I know several companies that also use NDLs on their intranets, allowing users to launch Notes documents directly from the browser.

These applications aside, I think that NDLs can be very handy from a productivity standpoint. In the old days, I used to have a single directory that I would use to store NDL files that linked to documents and views I used all the time. If I was in the middle of a task and needed to switch to one of those elements, I would just Alt-Tab to that open directory window and click the necessary NDL. If you spend some time thinking about the items in Notes that you use frequently, you'll probably come up with a pretty good list. Creating NDLs for each of these elements is a simple way to speed access to them.

You might wonder why you would use this method over, say, just creating a document in Notes where you store all of your links. This is probably just as good an option as using NDLs, but I chose this approach for two reasons. One, it was faster for me to Alt-Tab to the open window rather than navigating to another Notes document and two, it allows me to have access to these elements quickly even when I'm not in Notes. In fact, if Notes isn't open, invoking the NDL will open the client and then navigate directly to that element. From a productivity standpoint, this seemed to work very well for me. However, my life wasn't quite complete until I found ActiveWords.

NDLs on steroids...Combining them with the power of ActiveWords

Watch out, 'cause I'm going into all out fanboy mode for a minute. One of the greatest software purchases I ever made was a little product called ActiveWords. ActiveWords is a program that allows you to truly take control of your computer. Basically, when ActiveWords is running, it is monitoring everything you type, no matter where you are. When you type a word or phrase that you've setup as an ActiveWord, you can immediately trigger an action to happen. For example, when I type 'xl' and then hit the space bar twice, Microsoft Excel launches. If I type 'gm' and double space, my browser launches and takes me to Gmail. Whenever I want to insert my signature into a document, I just type 'sig' and appears. ActiveWords even has a cool module that corrects common spelling errors as you type! There are many types of actions that you can associate with ActiveWords. You can use it to substitute text, launch programs, open directories, etc. I don't want to turn this into a big ActiveWords commercial, but trust me when I say you need to do yourself a favor and head over to their site! Check out the demos and then download the free trial. It really is a revolutionary product.

Anyway, back to the point of the post. Combing ActiveWords and NDL files has allowed me to become even more efficient when working with Lotus Notes. Basically, when I have a commonly used link, I create the NDL file, place it into my NDL directory and then I associate an ActiveWord with that NDL. I can be most productive when my flow state isn't interrupted when trying to find information and I find that this combination is incredibly powerful. Let's say I'm working on a document and I need some detail about one of the servers in my domain. In a traditional scenario, I would have to open the NAB, navigate to the Servers view and then find the info I was looking for. Using NDLs and ActiveWords, I can maintain my context and just type 'server' and trigger ActiveWords (I do this by hitting space twice, although you can change the trigger in the options). The 'server' ActiveWord is setup to open 'LNServers.ndl', so as soon as I trigger it, the NDL is executed and the NAB opens right to the view I need. If you consider how often you access common elements in Notes, this simple action can add up to some significant time savings.

As with most of my posts, this one was written in response to an e-mail I received. Perhaps you'll find NDL files to be as useful as I have. If you have another approach that you use for accessing commonly needed elements in Notes, please feel free to share in the comments. If you have any other tricks for being really productive in Notes, I'd love to hear those too. If you're interested in a live demo of ActiveWords, please don't hesitate to ask. You can find me at the upcoming ILUG 2007 and Lotus Developer 2007 conferences. Cheers!

P.S. I have no stake in ActiveWords except for being a very satisfied customer. It's a software package that performs one particular function and does so exceedingly well. I highly recommend checking it out. I believe the purchase price is very reasonable for the value it adds.

Sunday, May 13, 2007

Happy Mother's Day...

I just wanted to wish a very Happy Mother's Day to my Mom (You're the best!), to my Mother-In-Law (for having such a great daughter) to my Grandma (who still looks radiant) and to my beautiful wife.

Especially to Maria...we have some pretty amazing kids and I'm pretty sure that you've contributed to that somewhat! ;-) Thank you for everything you do for all of us!!!

Happy Mother's Day...I love you all!

Friday, May 11, 2007

Woot! Less than two weeks away now...

Poor Usability Site Of The Day

Check out the Avis website in IE. Try to hover over one of the tabs and then make a selection. Whoops! If their intent is to just show what is available in each section, they should have used a different mechanism. Is anyone not thrown off by how that's working now?

(Thanks, Joanne)

Friday, May 04, 2007

Sneak Peak: Build A Better Burrito...the Notes Way!

Click for animated demo

Want to see more? Make sure you catch me at ILUG 2007 or in my 'Advanced User Interface Techniques for the Notes Client' session at Lotus Developer2007. Was making a burrito ever this good? ;-D