Don't Assume...Your UI Should Help Guide, Not Hinder
Today I was working with an internal system. I was filling out a web-based form and got to a required field in which I could not enter any data. It was rather annoying and at the time I couldn't figure out what the problem was. I knew I was probably working on one too many things at once, so I left it to come back and try to figure it out later. Sure enough I did, but even on second glance it wasn't obvious. The sad thing was, I had filled out this form once before and had the same problem, but because some time had passed, I had forgotten all about it!
Here's what it looked like.
Since you are probably a little more astute than me, you've likely guessed that in order to populate the field, you have to click on the label! Once you click the 'Product' link, a list of possible values appears in a modal dialog. So what's wrong with this? Sure it works and once I figured that out, all was fine. However, I wasted time that was completely unnecessary.
While the label is in a different color, it wasn't underlined, even when I hovered over it. There were no tool tips, so basically I had no idea that this text was actionable until I clicked it. The cursor changed at least, but when users are in a hurry, this is easy to miss. I've talked about the idea of affordance before. This is the concept that an object's properties or characteristics imply the functionality of that object. In this case, the label did not have any affordances that I normally attribute to actionable text except for the color, which explains why I missed it at first. I just thought the field was being highlighted for some purpose I was not yet aware of. The designer assumed I would take it's meaning one way, but I assumed something completely different. The old warning about assuming is definitely true in interface design!
In addition to the affordance problem, another glaring deficiency here was the poor learnability of the system. Learnability is a measure of how quickly the user can figure out the system and remember the functionality for next time. Because the designer used non-intuitive functionality, it was difficult to learn and then hard to remember. Now that this has happened twice, I THINK I should remember this, but if I don't revist this application for another 6 months, it's quite possible I won't.
When you are building your interface, remember that your goal is to gently guide the user through the task before them. Each element that requires input should be blindingly obvious and if not, you need to take some steps to make it so. The designer could easily fix the problem in this example by adding some text telling the user that they must click the field label to view the list of choices. Perhaps more elegant would be a button next to the field or in modern UIs, the ability to just start typing and using auto-suggest functionality. Any of these options would be fairly trivial to implement, but would go a long way toward increasing the form's usability.
As a designer, I challenge you to approach these constructs through a user's eyes. Better yet, make sure you are doing testing from the very beginning so that you can capture these issues before you write any code. Test early, test often and don't assume. Your users will love you for it.
As I was once again forced to use one of the most horrible software products I have ever laid eyes on, it occurred to me that it's worth repeating one of my favorite mantras, even at the risk of sounding like a broken record (do any of you kids even know what that means? ;-) --> Simplicity in your design is your goal. If you can get to the point where the interface "disappears" and the user can just get in the flow and do their work, then you've really got something there.
So many of the things we use on a daily basis, both software-based and not, are way more complex than they have to be. We're all too busy to be wasting time with complicated systems, yet in many cases this has become the norm. As an example, I recently had to replace my kitchen blender. A trip to Williams-Sonoma quickly became an exercise in frustration. Most of the blenders had so many features and functions that I was surprised they didn't contain a microchip or two. Multiple buttons, gadgets and add-ons all to accomplish a single purpose...blend some stuff up! In the end, I found the perfect blender for me...a replica of an old model that has a single switch for two modes: hi and low. When I want to blend something, my choices are simple and I can immediately get down to business without thinking about all the different options I have. It's actually pretty liberating to simplify like this. We use an old-fashioned manual can opener in the kitchen too. It works wonderfully and we don't ever have to worry about it breaking. Stuff used to have a singular purpose and did it without a lot of fuss and choice. I use this idea as the guiding principal in the work I do.
Now trying to compare a kitchen blender to enterprise software is a bit of a stretch, but I think you understand what I am getting at. There is quite a paradox at work when we give our users too many choices in our applications. When faced with a lot of choices, we actually find it harder to choose because we are wired to evaluate all of the potential options. Have you ever felt paralyzed looking at your To Do list because there were so many tasks you didn't know where to begin? This same feeling of overwhelm hits a lot of our users when they are faced with a complex interface, especially one that provides them with many paths to go down.
If you are building a business-facing application that will be used by actual humans, then you have a targeted objective you are trying to achieve. The interface should facilitate this process and it should provide the path of least resistance to do so. If it's easier to do it the old-fashioned way, users will ignore your app. It's important to focus on your interface so that it gently guides the user to their objective without getting in their way. One way to completely fail in this regard is to provide too many choices and ways to accomplish the same task.
So how can you practically apply these ideas? Evaluate each and every element you place on the screen. Make features and functions fight for their lives. If an element does not have an explicit reason for being on the screen at the time a user is performing a particular task, then it shouldn't be there. Keep controls very simple and related to the context the user is currently in. Generously use whitespace.
These basic ideas seem to be simple common sense (and they are!), but I've seen far too many applications that break these rules. I don't know a single person that wishes their life was more complex than it already is. Keep the concept of simplicity at the forefront of all of your designs and I promise that your users will thank you.
It's All About The Whole Package...Designing for the User Experience
While the title of this site is Interface Matters (because I thought it had a good double meaning to it and it reflects an area where many Notes applications have issues), I'm really more inclined to think about the entire user experience (UX). Now certainly, the user interface is one important aspect of the user experience, but UX is much more than just what the screens look like and what the user sees. I'm an advocate of taking a holistic approach to the art and science of application design. I want every aspect of the process to be all about the user...making them happy and productive. Let's be honest here. If you are reading this blog, it's most likely because you are a developer in a corporate capacity in some shape or form. And that means that the users don't necessarily choose to use your software. They may request that it be written for them, but not because they are looking to have fun. In many cases, they are unwilling victims that must use it, no matter how bad it is. If that's the case, then I think we have an imperative to make the user experience the best it can possibly be.
I think I'm going to explore this in more detail in subsequent posts, but let's lay the foundation for what user experience is all about. In my definition, the UX is every interaction that a user has with a software application, from beginning to end, cradle to grave. Thus, the user experience encompasses:
- The project request
- The initial meetings with the customer (business/requirements gathering, proposal)
- The design phase (prototyping, usability testing)
As you can see, using my definition, we're talking about the entire lifecycle of the project. And how you engage and interact with the user at those times when you are not even dealing with code is just as important as when they are sitting in front of the screen. In some cases, those events are even more important. The reason for this is simple. Our brains are great at associating events. If you start out a project on the wrong foot, even the best deliverable in the world might not be able to keep the user from thinking that the application is not that great. I've seen this happen in my own experience. I used to have a co-worker that was quite arrogant and rude. This person thought they had all the answers and subsequently alienated every customer we talked to. While the project this person engaged on was delivered ahead of schedule (and was quite good, I begrudgingly admit), the adoption of the application never took off. After this person left, I inquired as to why when the project was eventually resurrected. It turns out that the people in the department knew there were going to be other phases and more enhancements, but they didn't want to deal with this person! So here you had money spent, people's time invested and an inefficient business process that could have been much better, but people rejected the application because they didn't like working with the developer. That, my friends, is a breakdown in the user experience and it has absolutely nothing to do with bits or bytes.
I know that many traditional application developers claim that they don’t "do UI” almost as a badge of honor. As such, the idea of designing for the User Experience is probably even more foreign to them. However, I think it is vitally important to start to overcome these challenges. This will come about only through an organization making the necessary cultural change. Before app developers can actually start making progress in developing a good user experience for corporate applications, the process needs to support this objective. This means that designing for the UX needs to be injected into the design methodology. Whether they use traditional methods or an agile methodology, thinking about and designing for the user experience needs to be woven throughout the process. When your organization steps up to embrace this idea, it's amazing to see the transformation that takes place.
Have you followed a user-centric approach in your design process? Has it changed how you work? If so, I'd love to hear your story. I plan on sharing some more of my ideas in this space next time.
Why Do Enterprise Applications Suck? And How Can We Fix It?
Originally, this post was just going to be a link to a great article, but as usual, I seem to have a little more to say. Before you read my thoughts on the subject of sucky enterprise apps, please check out what Michael Nygard has to say on this topic.
Good stuff and I whole-heartedly agree. To summarize, Michael postulates that there are four main reasons that enterprise applications suck in terms of the user experience. They are:
1. The serve their corporate overlords, not their users.
2. They only do gray-suited, stolidly conservative things.
3. They have captive audiences.
4. They lack "give-a-shitness".
I think most of us in the Notes world would be hard pressed to say that these things aren't true in many of the applications that we've seen (and perhaps even authored ourselves in the early days). I often lament the fact that the majority of us learned our craft by deconstructing the Notes templates. While they were certainly great back in the day and the underlying code is slick, the fact is that the users' expectations of the software experience has moved on and we as developers...not so much.
I originally started this site knowing that it would be a niche within a niche. Interface Matters is about Lotus Notes development with a focus on user interface design. If you ask a lot of people, those things don't usually go together. At least they didn't. But I'm happy to say that Lotus and IBM get it now. Certainly we can't turn around on a dime. We're a huge company after all. But if you look at the progression between past clients and Notes 8, it's a pretty outstanding evolution. In my sales role, I'm starting to see a lot of traction in upgrades to 8.5 and this presents developers with an incredible opportunity to start rallying against Michael's "4 sucky apps" theory.
In order to overcome the sins of the past, you've got to start injecting the idea of a compelling user experience into all aspects of your design process. It's not just about how things look. Instead, it's about the entire experience, from the time you begin to engage the users to gather requirements to after project delivery. How do they report problems to you? How responsive are you to issues that are raised? Are you thinking about fast release cycles? All of these things are part of the user experience and I don't think I'd be off base by saying most are neglected in traditional Notes development.
To turn this around, begin leveraging best practices in the UX space. Try using "Web 2.0" design patterns (like those found at UI-Patterns.com). Examine what well-known sites are doing and determine how they are keeping users engaged. Even better, ask your users what they like. I've received some of my best ideas from the users themselves. It's very eye opening to watch them work or to discuss what sites on the Internet they find easy to use and why. The best advice I could give a programmer is to attempt to "step outside the code". The code is the solid foundation upon which a great app is built, but like the foundation of the building where they live, the user never sees it. Instead, they see their house...a place that is comfortable and that they call home. The same is true for your app, so our goal is to not only lay that solid foundation, but to create the most attractive and comfortable environment that we can. Once you make the mind shift from lines of code to "how will the user feel about this?", then you will be on your way to developing a more compelling user experience.
As developers, we're the ones on the front lines that can make this happen. More than other platforms, Notes developers often have to play the roles of business analyst, designer, tester and programmer all rolled into one. The concepts of user experience are important in the work that all of these roles take on, so by making this a standard part of your engagement model, you'll be able to effect real change for the better and help make enterprise apps suck a little less. Good luck...your users are counting on you!
Thoughts on the eProductivity Install...Smooth Sailing Really
As part of the eProductivity challenge that I'm working on with creator Eric Mack, I promised to blog about the process and my findings as I went along. I thought this would be very useful for those people that are interested in the promise of achieving higher productivity using Lotus Notes.
The first part of getting things done with eProductivity was to actually perform the install. This is very easily accomplished since this tool was designed specifically for Lotus Notes. You'll be using your production mail file, so the one thing you must be aware of first is that you need to have access to update the design. If you're not sure, check with your corporate IT department. Assuming you have the proper access, the install will consist of replacing the design of your mail file with the eProductivity template.
Right off the bat, Eric and team have done a nice job of fully documenting the install of the software. Of course, I wish there were some kind of easy installer for Notes apps in general, but baring that, having a good set of instructions for exactly what settings you need to have in your ACL, how to replace the design, etc., is great. I didn't need the instructions for replacing my database design, but I would feel totally comfortable with an end user taking the documentation and getting right to work. Once the eProductivity template has been applied, a wizard (nice use of UI design pattern here) appears to guide the user through the remainder of the setup process. This consists of accepting the license agreement, setting the initial preferences (where it is recommended you take the defaults unless you are a more advanced user), and updating the design of any folders you already have to add the eProductivity features to them. Again, this is nicely explained and should give the user a feeling of confidence when going through on their own.
After the installation of eProductivity is complete (a process that should only take a few minutes at most), opening your mail file presents you with the main eProductivity UI. The user interface was designed to the standard put forth by the design team at Lotus for Notes 8 (Basic). I must admit to missing the Notes 8 Standard views for their sexy looks, but that feeling was short-lived, especially in light of my improved productivity. When you open your mail after the installation, you'll see a couple of cool features right away. One is the "Tip of the Day". I find this to be quite valuable. Since most users (myself included) would rather just get to work than wade through a big instruction manual, the "Tip of the Day" allows you to learn more about the features of eProductivity in small chunks. You may not figure out all the nuances of the software from day 1, but by using the Tip feature, you'll soon learn many of the tricks and more advanced things you can do.
The Tip of the Day feature
Another key feature is the "Today" view, which gives you a quick, at-a-glance way to see what lies ahead of you for that day. I'll review this more in a future post, but basically it aggregates your calendar, due action items and tickler entries so you don't have to go through multiple views to find out what you should be working on today.
The Today View
So that's it...the installation for eProductivity is a breeze. I think the user experience around this was well thought out and allows the user to get up and running in very little time. In fact, it will probably take longer to download all the materials than it does to perform the actual install! :-) If the install is the easy part, what about using eProductivity itself? I'll be saving that for a future post. Let's just say that getting the GTD methodology right takes some time and dedication, but eProductivity seamlessly supports this methodology and so far has helped me to get information into the correct place better than any other system I've used before.
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!
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.
Epic Fail...Error Message Worst Practices (And How To Fix Them)
Error messages...the bane of users. We all dread the software crash or programmatic wrong turn that sends our productivity crashing into a brick wall. To add insult to injury, I think most of us would be hard pressed to find examples of good error messages in the software we use. Remember that one of the key goals of interface design to strive for is making the interface unobtrusive so that the user can focus on the task at hand, not on how to use the software. When users encounter an error, we are rudely pulling them out of their productive work and bringing the deficiency of our application to the front of their attention. If we can't avoid the situation that brings forth the error, the least we can do is handle it in a graceful and helpful way. Sadly, this concept seems to be the exception rather than the rule. I've often found that it's useful to perform some analysis of applications that fail to meet user expectations in order to learn better ways to do something. Let's look at some examples of error messages gone awry (the worst practices) and then figure out to fix them.
OK...thanks for that
And why, pray tell, am I not?
Eh? I don't speak Klingon.
Oh yeah...System error &H80004005. How stupid of me to forget!
Not only have you offended me sir, but you've scorched my retinas!
If only the girls at school were that easy.
The thing that all of these messages have in common is that they don't result in an action. That is, the best they do (and that is arguable) is tell the user something went wrong, but they don't address the most important part of the whole event..."WHAT SHOULD I DO ABOUT IT?!!!" If you were asked to determine the disposition of this user after encountering such error messages, what would you imagine they would say? Yeah...something along the lines of "Oh crap...here we go again with this piece of $*&@! application!" And you know what, I certainly wouldn't blame them for thinking that! Some errors are certainly worse than others. The most heinous offenders are those that only provide a very technical message that accomplishes nothing but making the user even more anxious.
The error messages that at least provide a "plain English" (or insert your language of choice here) description of the error are better than nothing, but are still not doing things quite right. Another sign of a bad error message is one that does not give any indication of whether the machine/software was at fault of if the error was due to the user's actions (e.g. stack overflow from a numeric calculation vs. user entered text in a number field). All in all, these bad characteristics and worst practices end up making the user feel stupid. Since our work as developers is supposed to be empowering users, then presenting them with less than perfect error messages means we've failed in that task.
So...now that we know what NOT to do, how do we go about fixing the problem? An important aspect of good error messages is that they provide enough information to the user so that he or she is clear about what to do next. The best error messages have some common elements:
*They tell the user what went wrong in plain English and do not make the user feel like they screwed up.
*They avoid technical jargon. If the programmer is the only person that understands the message, it is bad.
*They send an automated report to the developer (see the amazing OpenLog, created by Julian "The Genius" Robichaux. If you're not using OpenLog, you're doing it wrong!)
*Most of all, they tell the user what to do next.
That last point is critical. What the user should do as a next action will depend greatly on your environment, your policies and procedures and the error in question. Maybe it just tells the users to "Press Ctrl-C to copy this error to the clipboard and paste it into a new mail message. Send this message, along with the title of the error, to the help desk". Or it could give the user explicit instructions such as "Enter passcode 4331 into the highlighted field and press the enter key". What really matters is that the user is not left wondering what to do next. The error message should guide them to the next steps. The next action might not fix their problem, but it will at least let the user move on.
Here are a couple of good examples I swiped from the net. These messages address the criteria stated above. Notice the (in)famous Twitter "Fail Whale". No one ever said error messages had to be grey and boring.
I really love this one. It goes into extensive detail on what to do next. Do all of your errors have to be this detailed? No...but in some cases it might help.
The Fail Whale is fun and informative.
Remember that unexpected errors immediately cause users to cease being productive and often make them freak out. By anticipating possible errors and constructing good responses using the elements cited above, you'll be able to minimize the disruption and get the user on their way with the least amount of fuss.
So my call to action for you today is to review the applications you are currently working on. If your custom designed errors are more like the worst practices than the best practices, make it a point to fix them. Make them clear, helpful and actionable. Your users will thank you.
By now, if you are a member of the Lotus community in any way, shape or form, you've probably seen the great new press release that articulates the momentum we've been gaining (quarter after quarter) over our competitors. It's so great to see the commitment we've all made to this platform be validated in real world terms. I, for one, welcome our new Lotus Notes overlords. ;-)
In light of all the great press and positive upswing I've seen out in the wild lately, I thought it was interesting that I had the following conversation the other day. I was at a meeting with a customer...a large financial institution. They are a long-time Lotus customer and really do a great job taking advantage of the Notes platform. After a successful meeting, I was standing out in the hall talking with one of the VPs and he said to me, "We use Lotus Notes for so many things, especially workflow applications, but they are getting pretty long in the tooth." I was not expecting that comment, but I immediately knew what he was referring to. The thousands of applications this customer has are still providing a lot of business value, but the problem is...many of them look and feel old. In other words, the interface is what makes him think that perhaps it's time to do something new. I've been around long enough to know that this is not a new sentiment, but it's one worth shedding a little light on.
One of Lotus Notes' greatest strengths can also be its bane. With Notes, you can rapidly roll out a solution that addresses a business problem, usually faster than your colleagues that use some other technology. I've seen many of these applications continue providing great value to a company many years after they were initially deployed. The 100% backward compatibility allows these databases to keep on working version after version. This brings us to the problem of the interface, however. If an application was created in...let's say R4...that application is already over a decade old. If changes to the UI haven't been made, then of course it is going to look antiquated. Both the technology and interface conventions have changed a lot in that time and user expectations have greatly morphed in that period as well.
Here's the real truth: As developers, we no longer have the luxury of creating application that work but don't look good. You can't say "I don't do UI" any more, lest you want the Notes platform to disappear. The users of today are computer literate or at least savvy enough to know a good application experience from a bad one. The internet and Web 2.0 has established a precedent when it comes to usability and user interface design and we ignore this precedent at our own peril.
So...is Lotus Notes long in the tooth? Is it a tired platform that we need to send to the old folks home? Of course not. The fact is, the future for Lotus Notes is brighter than it's been for a long time. It is necessary, however, to start treating it like the modern development platform it is and that means that developers need to take a look at themselves and see if they have the requisite skills to create compelling UIs and usable applications on the Notes platform. If you feel you are deficient in this area, then here's my call to action:
- Start thinking about the user interface at the very beginning of your project. You don't necessarily have to use low-fidelity prototyping, but the interface shouldn't be an afterthought.
- Make usability testing a part of your standard development methodology. Then actually listen to what your users have to say and make the appropriate changes.
- Stop making all your Notes apps look the same as you did 10 years ago. Yes...I'm talking to you! :-) At a minimum, begin utilizing the User Experience Guidelines for IBM Rich Client Applications. Better than that, though, is to make clean and simple interfaces that support what your users are doing in your application...no more, no less.
I know many developers think the interface is touchy feely stuff, but the reality is that our software is judged by its looks. Lotus Notes now has a pretty face. Do your applications? If your users think that Lotus Notes is "long in the tooth", then your choice is clear...start fixing those interfaces or put them out to pasture.
Do you think about the simple bits that make using your application, website, etc., easier for end users? With the continuing specialization of certain applications, both within the firewall and out, I find that users are frequently interacting with these applications for very small chunks of time. Usually it is in the context of looking up some item of data, and it made me reflect on the ways I've tried to simplify life for end users, especially in light of short transactions. Here are some examples:
Putting an address all on one line so that it is easy to copy and paste into Google Maps or another system (e.g. 50 S. Front Street, Columbus, Ohio, United States 43215). When in edit mode, you would probably split the address up into its component fields, but this is a great technique since it allows the user to initiate a copy and paste action with a single selection. This concept applies equally well to other data elements that are made up of multiple parts. I constantly look up addresses so this idea is one I really love, but I don't come across it too often.
Type-ahead for frequently used names, words, phrases, etc. If users are constantly typing in the same text over and over again, be nice and give them a type-ahead mechanism. If something prevents you from using this technique (an old version of the software, for example), be creative and try to build some way for them to easily retrieve these common values (profile docs for individual users work nicely).
Pad link targets and buttons so that your user doesn't have to use a magnifying glass to find and click on a hotspot. The guys at 37Signals provided a couple of nice examples on their blog a few weeks back.
Provide an easy way to link to the current page of information. Sending a link (be it to a web page or an internal application) is something most users do all the time. We've been spoiled with doclinks in the Notes client for so long, but if you're not in the client (or even if you are but your users don't know how to make doclinks), simplifying this with some code that copies the current address to the clipboard with a single click or a similar idea goes a long way.
When in doubt, keep it simple! I've run across many applications that should have been great, but were hobbled by poor layout and even worse...too much visual clutter on the screen. This rule applies across the board, but is really important in the context of micro-experiences. If the user is coming in quickly to get some data and get out, the more you can facilitate this experience and make it a fast one, the happier your users will be.
So those are a few of the rules I try to follow...how about you?
Unlock Your Creative Side And Create More Compelling Designs
Programmers and IT types in general are not usually well known for their creative and spontaneous ways. Most in this profession are very logical and linear thinkers, and often those qualities lend themselves nicely to this field. An unfortunate byproduct of this fact, however, are the thousands upon thousands of badly designed applications that have been forced upon poor, unsuspecting end users. If you've been here for any length of time, you know that I have a couple of sacred mantras. One is that the interface is the application as far as the end user is concerned. They could care less about your SQL backend or cool use of classes in OO to abstract the blah, blah, blah. :-) Another is that because of mantra #1, it is our duty as developers to design everything with the end user in mind. Now...if you are a logical and linear thinker, then this might not be the easiest thing in the world for you to do. The key is to recognize that you need to work on developing your design skills and to continually grow them. One technique that can help in that regard is mind mapping.
Mind mapping is a technique used to visually depict concepts in a non-linear way, with lines radiating out from a central concept that group related items together. They are very useful in allowing you to see relationships in seemingly non-connected information. Mind maps are also great devices for brainstorming. The power of mind mapping comes from the fact that it allows you to utilize both sides of your brain, the creative and the logical. One of the key concepts of mind mapping is including multiple colors and pictures within your map. In doing so, you draw upon those creative tendencies, which just in itself provides value by keeping your brain sharp. Mind mapping began by using the same kind of tools you use for low-fidelity prototyping...pens, crayons, pencils, paper, etc., but you can also now find many mind mapping applications for the computer (stay tuned for an upcoming review of my favorite, MindManager). To learn more about Mind Mapping, check out the definitive work by Tony Buzan (The Mind Map Book) and another great work by Jamie Nast (Idea Mapping)
Click to enlarge
I think that mind mapping provides some great benefits for programmers and designers. One way I use mind mapping is to capture and display all of the little nuggets of information that I come across during the requirements gathering phase. I often find that seemingly insignificant remarks or off the cuff comments that don't appear important at the time make a huge difference to some design aspect of my application later down the line. By having these bits of information laid out in front of me in a mind map, I can occasionally find relationships in the ideas that the end users didn't explicitly spell out or I can identify areas where further interviews and exploration is necessary.
Mind maps work very well for project tracking and managing programming tasks as well. When I get down to the point of writing code, I try to capture the major design points in a map. I know many programmers who do this with basic To Do or feature lists, but by using a map, you can see how the various components of your design are related. It also allows me to visually represent the importance of one item over another, so at a glance it is easier for me to see what I should be working on.
I find mind maps are a perfect way to begin thinking about the hierarchy of a new application design. Items like navigation structure and UI design elements naturally lend themselves to the kind of relationships a mind map is designed to convey. If I'm working on a new website, for example, I'll create a mind map of the taxonomy. When I share this with end users, it's a lot easier for them to understand since they "see" how the website will be laid out. Remember the old cliche..."a picture is worth a thousand words". I think as much as you can simplify the design process for the end users with pictures and easy to read visuals, the closer you will get to meeting their requirements when you deliver the application to them.
Although I have not done this yet, I think mind mapping would be an ideal way to visually see how your LotusScript or Java code is laid out. I remember working on an application for "Really Big Company" that had tons of script libraries. I spent a lot of time when I was first learning the system digging through the various functions and methods and taking notes on what called what, how they were related, etc. I think a mind map could show these relationships much more elegantly. I'm going to try this whenever I get back to writing code.
Beside the applications mind mapping has in a professional development capacity, they can be used for almost anything else. I find that my memory of certain things is improved when I use a map over a standard linear way of writing information down. Mind maps are great for capturing meeting minutes, brainstorming, taking notes on a book you are reading, etc. But the biggest benefit and why I bring this topic up has to do with the creative nature of mind mapping. When you follow the "tricks of the trade", you begin to rely on both sides of your brain and unlock that creative potential that you have inside. In doing so, you'll find that your problem solving skills are sharpened and you can more easily envision the various dimensions of a given issue or task. I believe mind mapping also helps you become a better observer and certainly the act of creating a map helps commit what you are writing to memory much faster than any other method I've used before.
When it comes to designing innovative UIs that your users enjoy working with, creativity is key. I hope you'll consider mind mapping as one possible way to help cultivate your creative side. P.S. Here's a short little interview on what I do with MindManager.
Collaborate From Anywhere...The Value Proposition of Lotus Quickr
If I had to pick a common Achilles' Heel among the various collaboration systems I've worked with through the years, I would probably point to the fact that each system usually has a single point of entry. That is, you have to (virtually) leave the place you are currently working in order to go to the "place to collaborate". I've found this to be true of Lotus Notes document libraries and Team Rooms, Documentum, Quickplace and other web-based repositories and even Sharepoint (depending on the tools you are using). This creates a barrier of entry for a lot of people. They just don't want to have to open yet another window on their already crowded workspace in order to use collaboration tools. In addition, having to leave the context we are currently working in in order to share with our colleagues interrupts our flow state and makes us less productive. Just as effective collaboration has a cultural component that is vitally important, so too must the tools facilitate easily contributing to and consuming from the collective knowledge pool. Thus, one way to shore up that Achilles' Heel is to provide multiple entry points into the collaboration tool of choice. Lotus Quickr has introduced such mechanisms and by doing so really provides a compelling value proposition for team collaboration.
One of the driving goals for Lotus Quickr (and indeed the entire line of Lotus products) is the concept of collaborating in context. Collaboration in context is all about integrating content, tools and people (all the important components of the collaboration equation) within your business process. A great example of this is the Sametime presence awareness capability. If I'm in a TeamRoom and have a question about a document, I can immediately see if the author is online and can initiate a new chat session with them all from the place where my attention is currently focused. Quickr takes this idea to a new level through the Quickr Connectors.
If you've seen Quickr out in the wild, you've probably seen the web-based UI. While certainly shiny and new, this UI only shows one facet of the product. If you choose to, you can access all of the collaborative features of Quickr by opening your browser and navigating to your Team Place, but the beauty of the Quickr Connectors means you don't have to. Instead, you can access Quickr content and add to Team Places from where you already are. This includes:
Lotus Symphony (coming soon)
Quite an impressive list! IBM rightly realized that when people collaborate, there is usually some artifact that prompted the collaboration process. For most knowledge workers, this means we are authoring documents, usually in one of the tools listed above. Rather than making users take extra steps to get that content to the "place to collaborate", Quickr was designed to meet people where they are actually doing their work. This is a huge leap forward in my mind, as it removes that big stumbling block that plagues many collaboration initiatives.
Let's look at a couple of simple scenarios so that you see the power of Quickr. I think these will help in articulating the value proposition.
Scenario 1: Jim is an HR employee responsible for updating the company policy manual. This process involves making the changes in MS Word and then getting feedback from his colleagues before the changes are published.
Old Way: Jim has to locate the current, official policy document, copy it to his hard drive and open it in Word. He then makes the necessary modifications and makes sure he saves a new version on his computer. In order to collaborate with his colleagues and get their feedback, Jim then opens the Lotus Notes HR TeamRoom and creates a new document, attaching the Word file to it. This process, while not difficult, is inefficient and requires that Jim do a lot of task switching.
New Way: With Quickr, Jim's life will be a lot easier. If the HR policy exists in a Quickr site, he can open it directly from Word, make his changes, and save a new copy back to Quickr...collaboration in context.
Click to enlarge
Scenario 2: So much collaboration takes place today by people sending attachments back and forth in e-mail. This is extremely inefficient for many reasons. For users, attachments are the single biggest cause of being thrown into "mail jail" (i.e. exceeding quotas). In addition to the requirements from a storage perspective, there can be version angst...you find yourself wondering if the version you have is the most current one. With the integrated Quickr shelf in Notes 8, you can solve these problems. The Quickr shelf allows you to see all of your Team Places and access data from them directly from Notes. You can drag and drop attachments from an e-mail message into a Place. You can also drag an attachment out of a Place and into an e-mail message. Quickr is smart enough to add this attachment as a link rather than an actual attachment.
Click to enlarge
To help you remember to use your collaboration tools when you are sending e-mails, Quickr will detect if you have any attachments in your message and will prompt you to save them into Quickr. You can select the Place to move the attachments into and then the attachments will be replaced with links to the newly added Quickr content.
Many of the other integration points work in the same way, utilizing common actions that meld very nicely with the system we are interacting with (drag and drop into Quickr from Windows Explorer, for example).
In my experience as a collaborative technologies consultant, once you get people on board with the idea that collaboration is important and valuable for them, the next hurdle is getting them to actually use the tools. Lotus Quickr with the Quickr Connectors makes a very compelling case for simplifying adoption and helping your users get over that hurdle. I think we'll see this idea of collaboration in context start to embed itself in more and more collaborative tools and I am really looking forward to that experience. I know for me that working with Quickr has been a pretty enjoyable ride so far.
If there's a particular drum I bang over and over again, it's the "keep it simple, stupid" drum. This term has almost become a cliché , but hey, "if the shoe fits, wear it". (Oh sorry, that was bad...just couldn't help myself ;-)
Anyway, when I was doing project work, I was always the guy advocating for people to "take it slow", "do things in stages", "no big bangs", "Amazon wasn't built in a day", etc., etc. I believe that quick, iterative steps yield better results, less bugs and get you to the end goal faster than big, monumental projects. The problem, it seems, is that companies like to have big, monumental projects. The bigger the company, the more monumental the projects seem to be. I think this is dead wrong. It's not the way our brains work, it's not the way people are most efficient and looking at the abysmal failure of so many IT projects, it sure doesn't seem to be the way to run a business. So why do we keep doing it? I guess if I knew the answer, I'd be running a shop somewhere instead of pushing software. :-)
In my "To Read" stack of magazines, I recently came across a jewel of an article in the April 2008 issue of Baseline. The cover story in this issue was a piece outlining the failure and eventual redemption of Symantec's new ERP implementation. A classic "big, monumental project", it was undertaken without really understanding the needs of the very people that would be using it. As they found out, such an oversight almost completely crippled their business. In the end, what saved them was a new project that put the focus on the user experience.
I don't want to rehash the article here...I highly recommend you go and read it...but I do want to point it out as a prime example of a project gone wrong because the final end goal wasn't made clear. That final end goal always has to answer the question "Who is going to be using this and how will this project help them do their job". If you're not asking this question and getting the answer in your project, then you are doing your users a disservice. Keep their goals in the forefront...that's why you're there.
Simulating Fieldset and Legend In The Notes Client
You may have noticed that the signal-to-noise ratio of UI posts on this blog has been rather low the last few months. This is, unfortunately, a bi-product of my current job at IBM. While I'm cranking away on a development project, the ideas are coming fast and furious. When I'm not, it's much harder to come up with ideas. It's really the fact that solving a business problem spurs creativity, while actively trying to come up with new ideas as you stare at a blank page doesn't result in much useful stuff to share. I don't really create applications in this new gig, thus no great interface revelations. I do know that I really miss it, however, and I expect I'll find a way back. In the meantime, I am trying to squeeze in the occasional work on some personal projects, but my free time to do this seems to be ever shrinking. Please stick around, because I do have some ideas to share as soon as I can get around to fleshing them out. I've actually got several draft posts partially done, so it's just a matter of getting away from the wife, kids, horses, chores, work, et. al and doing it! ;-). That said, here's a cool tip but one that is simple too...my favorite kind!
In the HTML world, a Fieldset allows you to group thematically related fields on a form together with a visual line bordering them to denote their relationship. In addition, you can use the Legend tag to give the Fieldset a title. These tags serve two purposes in that they visually show the relationship between the items and they make the form more accessible. Here's an example:
Of course you could get more fancy with CSS, styling both the Fieldset and the Legend.
So...a pretty simple construct, but I think you can see it's usefulness. Great...that's fine for the web, but how do we do it in the Notes client? Actually, there are a whole bunch of ways to accomplish this using standard Notes dev techniques. The two I've found most useful for my purposes are to either create a graphic for my Fieldset and Legend so that they look exactly like I want them to OR use a...wait for it...wait for it...LAYER! :-)
Let's look at the graphic approach first. In your favorite graphic editing program, create the top of the Fieldset with the Legend. Make sure to match the color of the border and text with the visual theme of your form. You should get something that looks like this:
Now go to Domino Designer and create a table that will serve as your Fieldset. Paste the graphic into the first row of the table (you might need to merge cells first) or paste it directly above the table (I'll do that for this example). In order to make everything line up, first size the table so that it matches the width of your Fieldset graphic. Then, turn OFF the top border of the table. Finally, set the Picture properties of the Fieldset graphic so that the Text Wrap is "Don't wrap, align bottom". This will drop the graphic so it fits snugly against the table, appearing to complete the border and giving you a Fieldset with a Label.
If you like using layers like I do, then you'll find that they are an even easier way to add a simulated Fieldset to your form. To do this, you simply need to create a new layer and position it on the top line of your table so that it looks like a Fieldset. This allows for easier maintenance as well, since if you want to change the label, you simply type the new value in the layer. You can also resize it, change the color, etc.
There are other ways to approach this idea as well. Daniel Soares suggested creating an inner table within an outer table. The inner table would take care of the formatting for your field elements and the outer table, which would be a single cell, would contain a background image. This background image would be the entire Fieldset border. You could make some fancy effects with this one.
If I did a poor job explaining this or if you'd just like to explore it in more detail, I've put a Notes client database out there for you to download. There is a single form in the db that shows examples of each of these techniques and you can deconstruct them to see how they are put together.
Yes...I blatantly used a G.I. Joe-ism in the title. Why? Perhaps just to reel you in from Planet Lotus ;-)
In my recent work with customers and all the hubbub around social networking and collaboration, it's quite evident that collaboration is cool again. I'd like to think that Lotus is playing no small part in this, as our offerings in this space are truly exciting. I'm more enthusiastic about Lotus than I have been in years and that's saying something since you know I'm a fanboy! :-)
But one concern I have is an issue that I encountered many times in my career as a consultant, and that is we are spending a lot of time driving home the technology component without a lot of emphasis on what I believe makes up the other half of a successful collaborative ecosystem: the culture.
If you are introducing the idea of collaboration for the first time or are trying to kickstart a stalled initiative, addressing the cultural component of collaboration is critical. It's not enough to have the best technology for supporting collaboration installed in your company...you must have people that will leverage that technology in the context of their business goals.
So what does a successful collaborative culture need to get started? Here are my ideas, but I'd like to hear yours as well.
*Collaboration Champions: Some folks that embrace the concepts right off the bat and serve as the "go to" people when other employees have questions and need assistance. These are usually the employees that "get it" immediately when a new collaborative technology is introduced and quickly become proficient in its use, both from a technical standpoint and from a business focused one.
*Provide Recognition: Many companies overlook the importance of praising a job well done. For many employees, helping others in a collaborative culture is an intrinsic reward unto itself, but they still value when their efforts are recognized. Rewards don't always need to be monetary in nature. In fact, the top providers in a social network or collaborative initiative often find the kudos to be the most rewarding aspect of participation.
*Proper Training: Argh...don't get me started about companies that don't train people on new technology. How often have we heard "Lotus Notes s*cks" because the users were unaware of how to successfully use the software. Yes, we wish all software could be so easy to use that you don't need any training, but with enterprise software we're not there yet. Thus, providing instruction is an important aspect of the collaborative culture.
*How Does This Help Me?: One of the most compelling arguments I've seen in a successful implementation of collaboration technologies is when the company can clearly articulate the vision to employees and answer the question "What's in it for me?". Let's be honest...while the recognition mentioned above certainly is a motivator for some, the majority of employees will just think that this is another one of those things management does to annoy us. ;-) If you can help employees see how this initiative will make their job easier, help them make more commission, not have to work overtime, etc., they'll buy into the movement much more quickly.
There's obviously a lot more to this subject and I've just scratched the surface here. I'll save more for another post, since I think a lot of you are sick of my long essays! :-) However, one point of note. Not many consulting organizations address culture as a significant part of a new customer collaboration engagement. I think there's some good business potential there. Who will tap into it?
I got asked a question the other day that I didn't have a great answer to. A reader wanted to know of a way to limit the number of characters that could be typed into a field (e,g. restrict the user's entry to 30 characters). I don't remember having a business requirement like that in a Lotus Notes application for a long time, but in the past I'm sure I would have handled it with some form of input translation or validation formula using @Length. I'm vaguely aware of a script library I had at some point that probably included some code to do this, but it's long lost in the catacombs of old databases from past jobs. Regardless, I knew that any of those old solutions would be far from elegant in today's interface. Nope, what I needed was to whip up a fresh approach that presented a modern UI experience. Here are the characteristics I would want if I was implementing this feature:
-Immediate feedback about how many characters I have left -Automatic trimming of my text entry once I hit the maximum number of characters -Unobtrusive changes to the UI as I enter a length restricted field -A flexible and simple way to implement the functionality multiple times on the same form.
Click image for animated version
First, the code that does the checking. I tried to make it fairly generic.
The textLimiter function accepts the name of the field to be checked, the name of the field that serves as the counter and the maximum number of characters as arguments. In the If statement, we compare the number of characters (inputField.value.length) to the maximum allowed. If the string in the given field is longer than the max, we use the substring function to trim it to the appropriate length. If not, then we know we haven't reached the max length yet and the user can still type characters into the field. As they do so, the Else statement updates the value of the counter field by subtracting the length of the string in the given field from the maximum allowed number of characters. Pretty simple, no?
That's all that is housed in the JS Header of the Notes form. Now let's take a look at one of the fields that implements this code. For purposes of this example, I added the functionality to two fields. For each, I used the onFocus event of the field to initiate the call to the textLimiter function and used onBlur to clear the setInterval method. You can see how this appears in the "UserTitle" field below:
(Editor's Note: I used some creative editing to show the two events in the same screenshot)
As you can see in the onFocus event, I just set some variables for the given field then use setInterval to call the textLimiter function every 10ms. inputName is the name of the field you are limiting the characters in, counterName is the name of the field that is counting down the number of characters remaining and charLimit is the maximum number of characters allowed in the input field. The onBlur event includes the call to clearInterval, which means the client will stop invoking textLimiter as soon as we exit the field. (We'll skip the other stuff for now and come back to it later).
With just those few pieces in place, the functionality works quite nicely. As you type in the given field, the text underneath updates you with a message as to how many characters you have remaining. It's not enough to stop here, though. In order to keep the screen as streamlined as possible, I don't want any user input messages to be displayed except for when I need them. This speaks to the third point in my list of requirements. What I want to happen is for the helper text to appear as soon as I enter the field and disappear as soon as I leave it. That's where the rest of the code comes in.
I chose to implement the dynamic nature of this functionality with simple hide-when formulas. I placed the helper text on a separate line, then set it's hide when formula to hidden except when the "CheckField" counter was equal to the name of the counter's corresponding input field.
The first line sets the value of "CheckField" to the name of the input field that corresponds to this counter and the second line "clicks" the hidden button, refreshing the doc and showing the counter line. When the user exits the field, we just do the reverse, setting "CheckField" to null and refreshing the document again to hide the counter.
When you put all this stuff together, you get a nice little bit of functionality. It accomplishes the goal of restricting user input and does so in a fairly elegant way. You also get a handy little example database where you can try this out yourself.
Addendum: Well, what do you know. Had I not already done the work and typed up half of this post, I would have just quit this as it turns out that Mr. Robichaux has done something very similar. Our approaches were quite alike, but I think this one has at least one advantage in that it keeps the field trimmed at the set number of characters. In any case, if you'd like to see how he tackled the problem, check it out here.
Hey...Why Should I Care About The Interface? (Or...That's Just Touchy Feely Stuff, Isn't It?)
Because I'm a big fan of code reuse, I'm going to shamelessly copy and paste an essay I wrote when I first moderated a forum for LotusUserGroup. It's about why I think UI design in Lotus Notes is necessary and I believe it's an important talking point. I'm finding that as organizations are getting serious about deploying Notes 8, more developers than ever are interested in the concepts of usability and interface design. I've noticed an uptick in the amount of mail I'm getting from people who have just found my site, so this also serves as a good introduction to what this place is all about. Cheers!
If there is one question I have been asked most often by Notes developers, it is "Why do you spend so much time designing the interface for your applications?". The one line answer to this is "Because to the user...your interface IS the application". Because of the very nature of our jobs as developers, we tend to get wrapped up in the technical details. We love to come up with innovative new tricks, revel in writing a particularly efficient block of code and geek out when it comes to the latest and greatest technology. All of this, however, pretty much means squat to the guy or gal sitting in front of the screen trying to actually do something with your masterpiece. Users don´t really care about what´s behind the curtain. Rather, they are interested in one thing when they are using your application..."How can I get my job done quickly, efficiently and easily?!"
The goal of any good interface is that it should be unobtrusive. You´ll often hear designers talk about "getting the interface out of the way". This is your ideal to strive for. When your user can enter a flow state and accomplish the task he or she set out to do, WITHOUT having to think about how to USE the application, then your job as a designer has been highly successful. To put it another way, the developer is given the task to make the product transparent to the user. The goal isn´t to get people to like your application...it is to make it so that they don´t really notice the application at all. In the end, a clean, usable interface means happy users.
"OK...enough with the touchy, feely stuff", you say. "My users are business professionals...they don´t care what it looks like as long as it gets the job done!" Boy, have I heard this more than a few times. In a few special cases this might be true, but believe me, for the most part your users DO care. There are many benefits to designing a good interface. Although somewhat hard to put an ROI on, good UI design often saves money, since the users tend to request fewer changes. User acceptance of the applications is almost always higher than when the interface is ignored and users report greater satisfaction with the end result. Remember that it is human nature to want to use things that are functional and attractive. This fact is what makes the iPod such a spectacular hit. It´s just one of many MP3 players, so what makes it so great? The combination of aesthetics and usability (it´s so easy even grandma can use it) help it stand out in the crowd. To bring it closer to home, if you´ve ever had a user choose an inferior product over another more robust one simply because "it looks better", then you´ve experienced why interface matters. Perception plays a huge part in satisfaction.
So...if you are convinced that designing a good, usable interface is important, how do you go about accomplishing that task? There are many ways to start learning about usability. There are several great books on the subject and many websites that are great resources. I´ll post a listing of my favorites in a separate thread. My main point of advice for Notes developers would be to practice what I call an "interface first" design methodology. Basically, I use a pretty typical RAD approach to Notes development, but I have factored in UI design as a major component of that. The initial efforts that take place with an interface first design approach focus on determining what the user will see and do in the application. I am concerned at the very beginning with what the UI will actually look like because how the user will work with the interface elements usually has a direct impact on the code you have to write. As an example, I had a complex application in which multiple "child" documents had to be created for a given "parent" document. I could have simply used the standard Document and Response type forms with all the functionality that Notes provides for me, but in doing the initial UI design work, we came up with a much more elegant and simplified solution...at least simplified from the user´s perspective. In the end, the design used an embedded view/embedded editor model, which was harder to code but made the UI extremely easy for the end users, who were all new to Notes. Had we not focused on the interface in the beginning design stage, the application would not have been nearly as successful.
Employing an interface first approach takes a little getting used to in the beginning, but pays huge dividends in the end. How many times have you gathered specifications from a user, built the functionality and delivered it, only to have the user tell you that it´s not really what they wanted? Be honest...it´s probably more times than you´d like to admit. Have you ever thought up a cool design feature that you were sure they would LOVE, only to find out that they don´t use it, or worse, don´t LIKE it? I´m sure this has happened to the best of us. By using an interface first design method, you can avoid many of these problems. It´s not fool-proof, but it gets you a lot closer to the desired end result a lot faster than traditional methods.
So what does using an interface first approach actually mean? By using this method, you actually build the interface for your application BEFORE you write a lick of code. This can take many different forms, but essentially involves drawing out what all of the screens will look like as a first step. I use low-fidelity prototyping for all of my projects. This is just a fancy name for sketching out the interface on paper...using pencil, pen, crayons...whatever you have handy. Some people prefer to use HTML or a graphics program to design screen layouts. This is fine too, but takes more work. After I have gathered enough requirements so that I feel I have a good grasp of what the user is looking for, I grab a stack of fresh blank paper and jump into the design process. I draw out the fields, sections, graphics...everything that I expect will be a part of the application interface. This doesn´t have to look good. In fact, I encourage you to not spend a lot of time drawing these screens. They´re very likely to change and you might have to do this several times.
After your paper prototype is complete, schedule another meeting with your customer. Ask them to look at the screens and give you feedback. This can be formal (conducting a full-fledged usability testing session) or very informal...whatever you are more comfortable with. Take time to explore different scenarios. If your database is for entering customer complaints, ask the user to take the role of a customer service representative and have them walk through what they would do while looking at your paper prototype. Ask them to talk out loud as they do this, explaining each action. You´ll be amazed at the insight this gives you into the mind of the user. When you find something that doesn´t belong on the form, cross it out with a marker. Need to add some new fields? Just draw them in with a new color. See why it´s good not to spend a lot of time tweaking your prototype? You´ll end up changing them a lot.
When you come back from your initial paper prototype session you may be surprised at how much has changed. If you nailed it the first time, good for you! More often than not, however, you´ve got some changes to make. Quite literally, you should go back to the drawing board and build the next iteration. For a typical application, I will build about two or three paper prototypes. This may seem like a lot of work, but in reality doesn´t take too long.
So...you´ve built your paper prototypes, gone through some iterations with your users and have a pretty good feel for what the interface will look like and how the application will function. Now what? Now, go about your business...doing what you do best. Start slinging your code, basing it not only on the business requirements, but also on the interface requirements that you´ve collaboratively developed along with the user. By designing the interface first, you are already halfway to user acceptance and in my experience, have also made the users more passionate about the application. They feel invested in it much more than in traditional programming methods, where you may have only met with them once or twice. When you finally deliver that application, I guarantee it will be almost exactly what the customer asked for...and that, my friends, is exactly why we do this!
Thoughts about Collaborative Technologies and User Interface Design...
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... ;-)