A blog post entitled "Holy Cow, This Is Cool Or In Which I Introduce A New UI Technique But Give It A Vague And Flavorful Title to Game People Into Coming Here From Planet Lotus Since No One Really Reads This Interface Stuff"
Hi All...I always seem to come up with these posts at times that no one is around, but what the heck. Lotusphere is almost here and I'm lucky enough to be presenting once again (more on that later). As I was driving to a customer's site the other day, I thought of this technique and after playing around for a few minutes, I found that it works great. If you like it, consider it an early Christmas (Festivus, Hanukkah, insert holiday of choice here) gift.
I really love many of the UI patterns that have become popular in "Web 2.0" applications. Among these, one of the techniques that you see quite often is that of the "Fade In/Fade Out" element. Let's say you want to display a status or error message to a user after they enter an incorrect value. Sure you can just use a hide-when and make the text appear or pop up a message in a dialog box. But that just isn't sexy. You can add a little spice to your app by applying this modern looking UI device. First, let's see it in action, then I'll explain what's going on.
Now...that's the Lotus Notes client you are looking at, not a browser. While it's a very basic effect, it enhances the user experience in a nice and subtle way. It helps draw attention to the fact that there is a new element on the page and does so in a way that is less jarring than a pop-up box or instantly having the message appear on the screen. The beauty of this technique is that it is very simple to implement in your application. Here's how.
The key to this technique is the versatile programmable tabbed table (I continue to find new uses for this design element....I love it!). What I did is create a tabbed table and set the text and background colors to get progressively darker for a fade in effect. Then, using script, I simply switched from one row to the next on a timed interval using Sleep to pause the necessary amount of time.
For purposes of this example, I hard-coded everything, but after going through the steps, you should see how easy it would be to modify this so it is dynamic. The picture below shows the six rows that I used for the table. I selected a base color for the final display box background and then used lighter shades of that color for the previous rows. I did the same thing for the text in each row. I haven't really thought of any hard and fast rules here...just play with it until it looks good to you.
Hint: I find it easier to do the formatting for a tabbed table as just a standard table at first, then switch it via the Table Rows property tab.
As you may recall, you can programmatically switch rows in a tabbed table by writing a single formula line such as FIELD $DisplayTable1:= "4", where DisplayTable1 is the name of the table as defined in the Table HTML Tags properties and 4 is the name of the row.
You can also change the row via script, which is what I did in this case. I resorted to using LotusScript since it provided me with a facility to directly control how much time I wanted between each row change. If you are going to use LotusScript to do the row switching, make sure you add a field to your form that is the same name as that of the table (e.g. $DisplayTable1), otherwise you'll get an error when you try to set this field in your code.
Once you have the programmable tabbed table setup and formatted as you like, you just need to write the script to display the table rows to simulate the fade in effect. If I was doing this in a production app, I would probably hide the table until I needed it, fade in to the message and then fade out when the user dismisses it. Thus, the code would look something like this:
Dim workspace AsNewNotesUIWorkspace Dim uidoc AsNotesUIDocument
This LotusScript was converted to HTML using the ls2html routine, provided by Julian Robichaux at nsftools.com.
Notice here that the first thing I am doing is setting a field called ShowMessage to "1", which is just a field I use to control the hide-when properties on the table. Then, I set the table to row 1, refresh the document and sleep for .15 seconds, switch to the next row, sleep again and so on until the final row is revealed. To fade out, just repeat the steps above in reverse. That's all there is to it. I told you it was easy.
In case any of that was unclear, I've created a sample database that you can download to deconstruct the technique. It is simple and elegant, which you know by now is my favorite kind. I hope you can find a use for this in your applications.
Now...I mentioned before about Lotusphere. Did you like that technique? Do you want to learn even more "Web 2.0" UI goodies? Well, it just so happens that I'll be teaming up once again with my friend Nathan Freeman to present AD212 - 10 Web 2.0 User Interface Patterns for IBM Lotus Notes and XPages. In this session, we'll be taking a look at 10 popular modern UI patterns and showing you how to bring them to the client and to XPages. I'm excited about how it's coming out and I hope you'll drop by to check it out.
In addition to my session with Nathan, I'm very pleased to report that I'm teaming up for the first time with Tom Duff, aka Mr. "Now I'm published in a popular CIO.com article" (go read it...it's awesome!). We're going to be presenting BP108 - Getting To WOW...Interface First Design for IBM Lotus Notes Developers (it's also being repeated in case you can't make the first session). This is an updated version of some of my past presentations and I'm excited about it because Tom will bring his unique insight into the process of moving from a code-focused orientation to a more holistic one. Please come by if you can (and we'll have some goodies to give away as well! :-)
That's all for now. Signing off so I can work on more Lotusphere stuff. I hope you all have a fantastic holiday and very happy New Year!
Flashback: The Low Down On Low-Fidelity Prototyping
Note: This is a repeat of one of my more popular articles. It is reprinted here after several requests. Since I have a lot more readers now than I did when originally posted, I thought it would be a good time to recycle it. :-)
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 right...it 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 right...you 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!
Balsamiq Mockups...A Very Cool Tool For Building Prototypes
As long-time readers know, I'm somewhat of a zealot when it comes to singing the praises of low-fidelity prototyping. Over time, I've found that it allows me to get to the best possible user interface faster than any other method. While I love breaking out the crayons, markers and paper, I do admit that it sometimes becomes more time consuming than I'd like if I have to keep redoing a certain screen. This is where I see a computer-based tool being very helpful.
In a past post, I introduced you to using electronic tools to build a prototype. Thanks to an e-mail I received from a reader (Cheers, Miguel), I've found another prototyping tool that I think could be *the one*. From what I've seen, it's full featured, very easy to use and allows you to create interface mockups in a flash. It's got a funny name, but the story behind it makes it quite apropos. Check it out...it's called Balsamiq Mockups
I'm not going to go into details on the features here, since the elegantly designed Balsamiq website already does that. I do, however, want to point out some things that make it killer:
* It's got a web UI as well as a desktop counterpart if you want to do offline work.
* The hand-drawn elements are well done and plentiful. There's a control, window or container for almost every UI situation you can think of.
* You can export the end result as a PNG or XML file.
* It just works.
If you've ever considered building low-fidelity prototypes but were put off by the idea of using analog tools, I'd definitely recommend giving Balsamiq Mockups a try. You can use the web interface directly from the site. Hopefully, I'll have the opportunity to test drive the desktop based version soon. If so, I'll be back with an updated review.
OK...so what are you waiting for. Go forth and draw! :-)
It seems some folks liked my idea from last week, especially the example screenshot showing a drop down menu in this "universal toolbar" area.
I received a comment and a few e-mails asking how this was done. Well...I actually wrote this up (along with a sample database) a couple of years ago, so today's show and tell will be a cheat, as I am just going to link you over to that entry. With that, here you go. Enjoy.
Editor's Note: The sample database that is available for download also includes all my experiments using layers to create cascading menus. Remember...Lotus Notes is like an onion...it's got layers! :-)
SnTT: Add A "Universal Toolbar" To Your Lotus Notes Applications
Hey, look at that: A Show-n-Tell Thursday post. Woohoo! OK...I've got to think up a better/more descriptive name than "universal toolbar", but I'm creatively challenged today. At least I got a post out...geez. :-)
If you think about most of your applications, there are probably certain functions that are executed more than anything else. Perhaps it is a particular search mechanism, running a certain agent or navigating to a given document. Whatever the most common action is, do you make it easy for your users to get to? By easy, I mean is it always available or at least one step away? If not, you might want to consider using the universal toolbar technique. It's a simple and elegant solution for many UIs.
Here is one example. In this application, the most frequent activity is to open a particular document. There are several different parts and areas to this application, but often the user needs to quickly get to one of the core documents by the key value (in this case a part number). In a typical Notes application UI, a user would have to navigate to the view that contained the document in question, then use the "Starts with..." quick find function to jump to the document and then double-click on the document to open it. This is at least 3 steps and for a very frequently used activity, I think this is too much. Instead, my universal toolbar includes the ability for the user to enter the Part Number and open the document directly, no matter where in the application they are.
As you can see from the screenshots, it doesn't matter where the user is in the application, they always have the ability to enter the Part Number and the application will open the document. This saves the users tons of time and they love it!
To do this, I add a small frame into the application frameset. This can be positioned anywhere really, but I find it works well near the top or under the header. This frame becomes the container for your universal toolbar, which is usually a form containing the functionality you want to make available.
If you look carefully, you'll also notice I use a border caption on the universal toolbar frame so that it can be hidden if desired, freeing up that screen real estate.
Here's another example of using the universal toolbar concept in an application. In this case, I gave the users drop-down navigation. Space was at a premium in this application, so we wanted to remove any links to the left or right side of the screen.
One other way I've used this is to allow the user to quickly add new documents without opening a form.
So that's it...pretty simple but very effective. Everytime I've added this functionality to an existing application, I've received rave reviews from users and thanks for saving them time. Give it a try in your apps and let me know how it works.
Lotusphere 2009 - Free Stuff! 10 Web 2.0 User Interface Patterns for Notes And Xpages
Hi again...as we gear up for Lotusphere 2009 and abstracts are being reviewed, you still have the chance to vote on the sessions that you want to see in the Best Practices track. I'm very pleased that besides getting to submit an abstract with Mr. Duff, I also had the opportunity to submit another with my partner-in-crime from the last two Lotuspheres! Nathan Freeman and I really enjoyed presenting our user interface sessions to many of you and now we want to take it to a new level. Actually, our justification for submitting this session says it nicely:
"For the last two years, we have presented on the theory and practice of UI design in the Notes client, focused primarily on compatibility with previous Notes releases. This year, we want to take a more concrete approach. Instead of theory and demos, we want to take a deep dive on specific UI patterns, primarily from recent Web 2.0 designs. We want to show specific reusable patterns such a rating systems, live filtering and inline field validation feedback -- with both rich client and Xpages implementations."
As far as what we want to do, please check out the abstract on IdeaJam. If you like this idea, please vote to let the content guys know you'd enjoy having this session on the agenda. We hope to get to see you there!
Yesterday was the deadline for Lotusphere abstracts, so I hope you got your ideas in. I'm really excited that there seems to be such a buzz around the conference this year (even more than normal, it seems). One of my former colleagues submitted a couple of ideas too, so I'm hoping he gets a chance to get up there and show off his stuff.
I actually ended up with two entries thrown into the hat and one Birds of a Feather idea. Both of the session submissions are with a couple of fantastic speakers, and as always, I'm honored to have the opportunity to present with them. I'll hold off on announcing one of them until I know he's cool with it, but I'm thrilled to tell you that the first session abstract was submitted along with Tom Duff! Tom has a great, casual speaking style and has become a beloved presenter at Lotus conferences. I hope if we get picked that I can live up to his expectations! This session will actually be quite complimentary to one of his other ideas. I, for one, am really looking forward to seeing the Moving From Plumber To Painter presentation.
Our proposed session is entitled: Getting To Wow...Interface First Design For Lotus Notes Developers. If you'd like to check out the abstract or help influence whether or not we get to do this session, please click the link above and vote over on IdeaJam. Many of the other proposed sessions are there and the fearless leader of the Best Practices track, Mr. Mac Guidera, is watching this space with interest. Looking through the list of ideas submitted so far, I think we are in for an incredible round of sessions in 2009!
Thoughts about Collaborative Technologies and User Interface Design...
About Me
Name:Chris Blatnick
By day, I work as a Collaborative Technologies
architect and champion the cause of usability and user interface design. But don't judge me
by my blog...I'm using a template. Cobbler's children and all... ;-)
Click the icon to be notified automatically every time I add a new post.
Search
Disclaimer
Since I work for Big Blue now, I'm compelled to say “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.” So there...
