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.
Forgive Them...For They Know Not What They Do...With Your App
If you've been following along with the home game, then you are aware that there are many excellent UI patterns that you can use to improve the user experience you deliver to your users in your applications. Today, I wanted to explore another simple yet powerful pattern: "Forgiving Formats". This pattern is perfect for those applications in which speed to data entry is key (or at least desirable in most circumstances). I know in many of the business applications I have encountered over the years, we tend to develop nice, complex forms to capture all of the data the customer says they absolutely need. When you come back and look at the database later, however, you often find that only a few key fields are filled out (just the required ones if you're using validation!). The Forgiving Format pattern is all about letting users enter those key bits of data quickly, without having to worry overly much about the way they are entering the content. This pattern puts the onus on you as the developer to do the heavy lifting, not the end user. Of course, this is one of the tenants of interface first design. It allows you to simplify the UI and make the problem really about the behind-the-scenes code.
A great example of the Forgiving Format pattern is Google Maps. When searching for an address, you can use a variety of inputs. For example, when searching for a location in my town, I can put in:
Aurora Aurora, OH Aurora, Ohio 44202 etc.
This flexibility allows me to focus on the job at hand, not on the exact way I have to format the address so that Google understands it. This lets me get my work done faster, so obviously it makes me a happy user.
You can apply this same idea to your applications. I find it can be useful both for allowing quick data entry for Notes documents as well as for use as a search mechanism. The underlying idea is simple. As the developer, you have to account for the various input types the user may enter and then code for those instances. In my Movie Review sample database, the main input is obviously movie information. While the form allows you to capture more data, there are only a few fields that are key to building a good database of movie knowledge. These include the movie title, the rating, the genre and the running time. I created a Quick Movie Entry option in the database to show this in action. First, let's take a look at how I implemented this.
I created a caption in the frame so that the user could free up screen real estate if they didn't want to use this option. It gets it out of the way if the user will be doing something other than data entry. However, if they want to quickly add a bunch of movies, they can expand the caption area and then will see an input line for the movie information. Of course you could break the input into a bunch of separate fields to capture the user input, but a single field is easier and more elegant.
I included a brief explanation of what the user should enter with this control. This particular pattern works best when you have information that is targeted to a specific objective and when the input is something that you can prepare for. Leaving it completely open ended would be incredibly hard to program for and would likely result in failure. In this case, I'm expecting those four particular bits of data and I want the user to enter them in that order, as specified by the help text. When you choose to implement this functionality in your own application, you will have to weigh how flexible you want to be with the input field and possible combinations of entries vs. the complexity of the evaluating code.
In the Movie Review example, the user can enter the title, rating, genre and running time and then hit the "Go" button. If the code successfully recognizes the entry, a new document is created in the database and the user is informed via a popup message (using the fade in/fade out technique). If the input can't be recognized, the user sees an error message.
As far as the backend code goes, it can be fairly simple or very complex, depending again on how flexible you want to make this functionality for the end user. In this example, there are two fields that I'm actually mapping to already established categories. The rating should obviously be a valid entry (G, PG, PG-13, R and NC-17) and the genre has values such as Science Fiction, Drama, Comedy, etc. To evaluate these, I used a Select Case statement. This allows for the "forgiving" part of this pattern.
In the case of the rating, one user might enter a NC-17 movie as NC17 while another might use X and another might use XXX. They could also use varying values of upper and lower case (e.g. Nc17, nc-17, xxx). For each of these different possibilities, a Select Case statement makes it nice and easy to evaluate the input. I did the same thing with the genres. For a Disney movie, users might enter options like cartoon, animated, animation, etc.
Below is the sample code behind the button. Feel free to use this as a guide, but remember there is no robust error handling in the example.
Sub Click(Source As Button)
Dim workspace As New NotesUIWorkspace Dim session As New NotesSession Dim db As NotesDatabase Dim uidoc As NotesUIDocument Dim movieDoc As NotesDocument Dim entryDoc As NotesDocument Dim movieEntry As Variant
Set db = session.CurrentDatabase Set uidoc = workspace.CurrentDocument Set entryDoc = uidoc.Document
On Error Goto ShowError
movieEntry = entryDoc.MovieEntry
'Here's where you are going to do the meat of your work. 'You need to determine just how much logic you want to put 'in place to decode what the user has entered. I've given a 'couple of simple examples below.
Set movieDoc = db.CreateDocument movieDoc.Form = "Movie Review"
'Let's deal with the title first Dim movieTitle As String movieTitle = Strconv(movieEntry(0), 3)
'Rating Select Case movieEntry(1) Case "G", "g": movieRated = "G" Case "PG", "pg": movieRated = "PG" Case "PG13", "PG-13", "pg13", "pg-13": movieRated = "PG13" Case "R", "r": movieRated = "R" Case "NC17", "NC-17", "X", "XXX", "nc17", "nc-17", "x", "xxx": movieRated = "NC17" Case Else movieRated = "" End Select
'Category Select Case movieEntry(2) Case "Science Fiction", "scifi", "sci-fi", "SciFi", "Sci-Fi", "Sci-fi", "Scifi": Category = "Science Fiction" Case "Action", "action", "Adventure", "adventure": Category = "Action" Case "Comedy", "comedy", "funny", "Funny", "humor", "Humor": Category = "Comedy" Case "cartoon", "cartoon", "animation", "Animation", "animated", "Animated": Category = "Animation" 'etc, etc.... Case Else Category = "" End Select
'Here you'd actually perform the task (such as creating the 'new document if everything validated correctly. It should 'if you are careful with your forgiving format. If movieTitle <> "" And movieRated <> "" And Category <> "" Then Dim newMovie As NotesDocument Set newMovie = db.CreateDocument newMovie.Form = "Movie Review" newMovie.MovieTitle = movieTitle newMovie.Category = Category newMovie.MovieRated = movieRated newMovie.MovieTime = movieEntry(3) Call newMovie.Save(True, False)
'Display cool fade-in success message here Else ShowError: 'Display cool fade-in error message here End If Exit Sub
This LotusScript was converted to HTML using the ls2html routine, provided by Julian Robichaux at nsftools.com.
When you break it down, I think that this a very simple UI pattern to implement in your applications. As always, it comes down to trying to simplify the user's task. While this pattern is not applicable to all situations, I can think of a good number of Notes applications I use frequently that could benefit from the Forgiving Format pattern. Does one of yours? Give it a try and let me know how it goes.
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?
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.
By now many of you have probably seen the great little comic on the "It's Just a Bunch of Stuff That Happens" site about Simplicity, but if not follow the link then come right back...
Pretty true to life, eh? I recognized the bottom example in many, many (many, many, MANY) Notes applications I have seen through the years and I'm sure you did too, which is why we all thought it was so funny in a sad sort of way. But I tell you what my friends, the idea of simplicity is sorely lacking in the enterprise software world and this causes an undue amount of headaches for our customers, for our bosses and for ourselves. Is there something we can do about it? Absolutely. We can say no to complexity in the applications that we design.
To be fair, although the comic is funny, it's not really being equitable as it compares Google and Apple to an enterprise application, but the idea is not so bad. One of the tenants I've tried to instill in younger developers as I've mentored them is that complex business rules do not necessitate complex interfaces. In fact, I think the opposite is true. We need to work even harder to streamline and simplify the interface when the complexity of the business world rears its ugly head. We're all overwhelmed with the amount of data we have to deal with on a daily basis, so we appreciate (and even long for) those things that are easy to use. If we're trying to delight our customers and make their experience in our applications a pleasant one, what better way to achieve this than to employ our skills to craft a simple solution.
Here's an example from my own experience. Some of you have seen this in my talks at Lotusphere or the View conference, but it bears repeating. I worked for a few years for a "global tire manufacturer headquartered in Akron, OH". They had a pretty mature Notes infrastructure that had been around for quite a few years and some pretty complex systems were developed in Notes by IBM consultants there. One of these was a beast of an application called Vendor Billing, but I affectionately called it the Hellspawn. (OK...I didn't really call it that at the time, but in thinking back I should have!). The Hellspan was one of those systems that you dread to come across when you're a consultant. A multi-tentacled, multi-NSF monstrosity that had become more and more bloated over time, since developers just added new features without refactoring or thinking about what future consequences their design choices might make. I don't believe anyone did this out of lack of skill or with any ill will toward future developers, but rather the reality of a complex business process coupled with a desire to make changes quickly and cheaply provided the perfect environment for such a system to come into being.
Vendor Billing...excuse me...Hellspawn, was a system designed to gather up information about all the various IT services an employee at Great Big Tire Company made use of. This was managed through a series of documents that basically captured the services a given person was "subscribed" to. In addition, other databases in the Hellspawn suite stored employee department information, billing codes, rates, etc. It also interfaced with some of the company financial systems that were not in Notes. At the end of each month, some *really* nasty and complex agents gathered up the information from the various databases, determined how large each user's mail file was, spun around twice and sacrificed a chicken to the Gods of Complexity and spit out a document for each user that listed their costs for the various services. All of this was pretty much backend stuff and this far was hidden from the eyes of the users (thank goodness!). Unfortunately, the final result, that cost document, was used in a series of views that the end users would interact with.
For a good 29 or 30 days out of the month, the users were blissfully unaware of the evils that were going on within the Hellspawn, but when it came time to for managers to review their charges for that month, there was no escaping the task to be done. At this time, a manager would open the database and navigate to the main billing view. Within this huge, *horizontally-scrolling* view, the manager could see the totals for each subscription for each of his employees. On average, each manager spent about 30 minutes figuring out their IT charges and it certainly wasn't a fun or efficient way to spend half an hour.
I was first introduced to the Hellspawn shortly after I started at Great Big Tire Company and I'll admit that I was a bit scared of it at first. Certainly the idea of Simplicity was far from the minds of the people that developed it. I've no doubt that they were smart folks. There were custom LotusScript classes to perform operations on linked lists and the like. I'm quite convinced that some programmers make things more complex than they need to be simply to show off their "mad skilz". There's certainly a place for that, but in my opinion it's not in enterprise applications. Thus, my first thought as I looked at this beast was that it needed to be simplified...greatly!
I started, as I often do, by building some quick prototypes that distilled the basic essence of the application down to a single question: "What were the charges for my department?" Once I determined that this was what this system was really trying to tell the end user, the interface became quite obvious and instead of a massive view with the ability to navigate to other massive views, it was just a single field to enter the department number a la the Google search box. When a manager entered their department (which was of course remembered for the next time) and clicked the button, the new code I wrote went out and gathered up the required numbers and showed them on a new document which functioned as the "monthly report". This was formatted in a clean and simple way, such that they really needed to spend no more than 30 seconds checking their numbers. That's a pretty decent time savings per month per manager, eh?
As I worked on the new UI, I also spent a great deal of time under the hood, trimming things, refactoring code to make it easier to read and hopefully more efficient. Even though the business rules were still complex, I strove to make the managing of those business rules as simple as possible. This is our challenge as application developers and is as much an art as it is a science. Based on the hundreds of Notes apps I've seen in my career, here are some ideas to get you started:
1. Not every database needs a three pane UI. As Nathan is fond of saying, "It doesn't all have to look like mail!". Pick the UI layout that makes the most sense for the task at hand.
2. Skinny down your forms and pages. Most developers try to cram too much into a single screen. Instead of this approach, try a more fluid design that brings the most important information for the current task to the forefront of the user's attention.
3. Use views wisely. Not only are views one of the biggest performance hogs, but it's not necessarily efficient to use a view to find what you are looking for. Provide other mechanisms to getting at the data in your app, such as a document search like in my example above.
4. Examine other apps that you find easy to use and try to determine the reason why you like them. See if you can bring some of these themes into your own applications. A great example of this is an ajax-type ahead feature. It was immediately evident when we first saw examples of this technique that it would be useful, but I really feel now that it is almost a must have. It's such a great device for simplifying data entry in many situations and I try to incorporate it into my designs whenever I can.
5. Think outside the box. Yep, it's a cliché but it's still true. Sit down with a piece of paper and make your design as simple as you can, trying to forget the bounds of what you can do within the client. Then, once your design is done, jump in and figure out how the heck you are going to do it. For me, this has been a powerful technique, as I've come up with some great interface tricks by "drawing myself into a corner". :-)
As my life and work gets busier and busier by the day, I am more convinced than ever that simplicity is one of the greatest gifts a designer, engineer, boss or politician can give us. I'm sure many of you feel the same, so strive to make the idea of Simplicity an integral concept in all of your designs and save your users (and yourself) from the Hellspawn.
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!
I've not read a lot of the "Dummies" series, but whenever I've picked one up, I've been impressed by the quality of the product. "Web Usability For Dummies" is no exception. In about 300 pages, the authors do a good job of laying the foundation for a solid understanding of the important aspects of usability. It looks like this book might be out of print now, but you can probably find a copy at your local library or via Amazon.com.
What I particularly liked about this book was the focus the authors give to the Usability Design Cycle. This is a process that helps answer questions about designing for usability and is broken into six steps that are performed in an iterative fashion. The usability design cycle starts with "Study the user", then leads to "Set goals", "Design", "Build", "Test" and finally "Deliver product". It's truly a cycle since the process should be iterative, each part building upon the previous step. As the authors state in the beginning of the first chapter, there are many good books out there that focus on the "build" part, but not nearly enough on setting goals, designing or testing, which arguably are the most important. Thus, they make this the thrust of the book and why I think it's worth picking up.
Chapter 1 begins the book with an overview of what web usability is all about. This leads into a discussion about studying your users (the first part of the usability design cycle) in Chapter 2. Sharp readers will remember that Mary Beth and her team kicked off the whole Notes 8 project by doing this very thing...studying what the users of Lotus Notes wanted, how they interacted with the software, etc. While the focus of this book is clearly on web design for external websites, there are enough nuggets of information that you can use for internally driven sites or application design in general. I liked the section in Chapter 2 that dealt with actual customer visits. I think this is something more developers need to do and this part of the book might help you become a little more comfortable with the process.
Chapter 3 looks into the whys and wherefores of setting goals for your website. This includes issues such as determining what needs of your users you really want to meet, creating actual business goals, using metrics and setting goals for the site's usability. This chapter rounds out the first part of the book.
Part II of "Web Usability for Dummies" (Chapters 4-6) is all about the design of usable sites and includes topics such as organization and site navigation. Part III (Chapters 7-9) explores the concepts involved in creating usable web pages. Since this book is several years old, there are bits and pieces which aren't really relevant anymore, but as a whole the ideas are still pretty solid. If you're a Notes developer who is just interested in usability in general, you can probably skip these parts of the book, as they are pretty specific to the web.
The final parts of the book deals with "Reaching a Broad Audience" (Part IV, Chapters 10-12) and "The Part of Tens" (Part V, Chapters 13-16). Subjects touched on include broadening the appeal of your site as well and several nice lists such as Do's & Don'ts, ten cool tools for usability, etc. Chapters 11 & 12 are my favorites since they deal with (surprise, surprise) usability testing! The authors feel that this subject is important enough to warrant two chapters and this book is probably worth tracking down just for their advice on the matter.
When all is said and done, "Web Usability For Dummies" is a fun, quick read presented in the standard Dummies fashion. Experienced designers may not find a lot of new material here, but this book would serve as a great introduction to many of the important concepts in the field of usability. With used copies available on Amazon for as little as $3.20, it wouldn't be a bad investment to add this to your reading pile. While certain chapters may not directly pertain to the work you are doing, the first part and last part of the book provide a very compelling case for usability and are certainly worth the cost of admission.
You've heard me talk about simplicity quite a bit on this blog and in my presentations. It's really one of the most important things I stress to designers. The easier you can make your software to use, the happier your users will be.
For a bit of fun and some insight into the art of simplicity (and some enjoyable Microsoft bashing as well ;-), check out this great TED Talk featuring David Pogue, tech writer for the New York Times.
One of the must have books on my reference shelf is "Don't Make Me Think, A Common Sense Approach to Web Usability" by Steve Krug. I've recommended this book to many people, so I thought it was about time to give it a proper review.
One of the things that first drew me to this book when it first appeared was the subtitle. I've said it again and again, but it bears repeating...much of the "science" of good UI design is just common sense. This begs the question as to why some people find it so hard, and I think the answer lies in the idea of common sense in our society. We are so busy being busy that oftentimes we don't slow down enough to really *think* about a problem and thus the common sense solution eludes us. A book like "Don't Make Me Think" is a great way to make you put on the brakes a little and examine the fundamental principles of usability. For those of you that aren't web developers, don't be scared off. Although the focus of Mr. Krug's book is web design, most of the concepts are equally extensible to other design work, such as building a UI in the Lotus Notes client.
If you've not read any books on interface design or usability before, this book provides the perfect intro into that world. As he mentions in the forward, this book is for those people or companies that don't have a usability professional on board or can't hire one for some reason or another. If you're like most Notes shops, you probably have a small budget since we can do so much with so little. By taking the ideas introduced in "Don't Make Me Think" you can be on your way to doing this work yourself very quickly.
The author's writing style is both casual and witty and he follows the advice of his title when explaining new concepts, breaking it down so you can understand the underlying psychology without getting bogged down in terminology or theory. Chapter 1 begins with an introduction to what the author calls "Krug's First Law of Usability": "Don't Make Me Think". Simply put, this means that your ultimate goal is to design your interface so that when you look at it, it is immediately evident what you can do and how you go about doing it. In this chapter, Krug explores some of the elements of design that put more cognitive load on us than is necessary and then demonstrates ways to reduce this load. This is done through both the narrative as well as excellent graphics which simply but elegantly display his point.
Chapters 2 through 5 begin the exploration of how we really go about using an interface and set forth the guiding principles we need to be thinking about when designing. First, Krug talks about the difference in what we design for (reading, more reading and even more reading in a set pattern) vs. the reality of how people scan through an interface in a seemingly chaotic way. He then extends on the lessons learned here by helping you understand the techniques you can use to design interfaces for scanning rather than reading. He addresses five important things you can do to achieve the goal of capturing user eyeballs as much as possible: creating a clear visual hierarchy, breaking pages into clearly defined areas, minimizing ui noise, making clickable elements obviously clickable and taking advantage of established UI conventions. This first section wraps up with a discussion of why we like "mindless" choices and the importance of good copywriting and how you need to omit all but the essential words in your design.
Chapters 6 and 7 focus on the elements that Krug believes you must get right in your design. Chapter 6 is concerned with laying out the fundamentals behind good navigation. Since this is an area I call a lot of bad designs out on, it's one that I really enjoyed. Krug discusses some of the basic concepts of navigation and why navigation is so important to a user. He deconstructs various navigation conventions and explains why they work or don't work effectively. He also addresses the good use of search, page names, breadcrumbs, and the tab metaphor. Chapter 6 ends with a number of great graphics which show several sites as they were designed and the author's analysis of what was wrong. He then shows a revised version based on what he would do and in some cases also shows the company's own effort at making some improvements. As they say, a picture is worth a thousand words, so it would be good for the reader to spend some time pouring over these excellent examples. Chapter 7 is devoted to the design of the homepage and how to best design that important first impression. As in Chapter 6, there are a lot of great "before and after" examples to round out the theory.
The next two chapters of "Don't Make Me Think" are concerned with how you make sure you did the right things in your design. That is, they focus on one of my favorite topics, the idea of usability testing. In particular, Krug wants the user to walk away after reading these chapters realizing that usability testing is within reach of every single developer out there. Sure, in the ideal world we'd all have a department of usability experts that are there to critique our designs and help us craft the most user-friendly interfaces possible, but we all know that our day to day jobs are far from the ideal world. Still, Krug argues, you can find value in any amount of testing you can do. Krug espouses some common sense thoughts about usability testing, such as the idea that it is an iterative process, that you should test early and often and that testing even one user is better than testing none. Once he convinces you of the importance of usability testing, he presents some simple to follow instructions on how you can carry out your own tests. As he points out, it doesn't have to be expensive or fancy. You really can do this stuff on a shoestring budget. Chapter 9 ends with a sample excerpt from a test session, which in my opinion is probably worth the cost of the book right there.
Krug wraps up the final chapters of the book with a focus on the larger concerns of interface design, such as why usability should be considered a common courtesy, where accessibility comes into the picture and how to deal with a boss that "doesn't get it". If you just want to cut to the chase and start improving your designs right away you can skip these chapters, but they do a nice job of summarizing at a high level many of the salient points of the book.
All in all, "Don't Make Me Think" is a thoroughly enjoyable read and a very practical book for those that aspire to create better interfaces for their users. Coming in at just under 200 pages with lots of clear illustrations, you can probably read this book in a couple of evenings, which is great for those of us intimidated by the 1000 page tomes that populate the computer section in most bookstores. Probably the best part of "Don't Make Me Think" is that it applicable to the work you are doing today. You can read a chapter or two and immediately start putting the concepts into practice and the value you'll get as you do so far exceeds the book's cover price. "Don't Make Me Think" is highly recommended and I hope you make the decision to add it to your reading list today. You don't even have to think about it! :-)
If you've been around here for awhile or seen any of my presentations, you've heard me speak a little on the concept know as flow. When building your interface, the absolute ideal that you should be striving for is helping your users achieve a flow state, that frame of mind in which everything else seems to fall away and you become completely immersed in your task, distractions are eliminated and time flys ("I've been doing this for 5 hours??? It seems like 5 minutes!"). There's a new article on A List Apart that describes this much more elegantly than I can, so you may want to head on over there and check it out.
So...some interesting results from the last post. I think that more people counted 14 passes than anything, although I think it is really 15. There's one hand off that's a bit hard to see. In any case, the number of passes really doesn't matter. What does matter is the fact that a lot of you didn't even see the gorilla walk through the video while you were intent on your task of counting passes of the basketball.
(If at this point you are saying, "What Gorilla???!!!", go ahead and watch the video again, not focusing on anything in particular this time, and be amazed. :-)
So, why did so many of us not even recognize the fact that a guy in a gorilla costume walked through the middle of the clip and beat his chest? The answer lies in how our brain works. In particular, it demonstrates a phenomenon called inattentional blindness...not being able to see things that are actually there.
There's a lot of good information available on the internet and in books on this subject, so I won't rehash it here. What I do want to point out is that you can use your knowledge of this phenomenon when you are thinking about the design of your applications.
Doug hit the nail on the head in the comments when he said "Or in Notes-land; What do you mean, you didn't see that grey button on the grey background sitting right there in front of your face at the top of the screen mixed in with all of that color and action on the rest of the form? You know the one that says 'HELP'? Weren't you LOOKING????"
I have found on numerous occasions where a user missed an important interface element due to innattentional blindness. In every case, the UI was so cluttered and complex that they really had to concentrate on accomplishing the task at hand. When they needed a certain function (that big button in the middle of the screen flashing "Click Me...Click Me"!), they completely overlooked it because their focus was elsewhere.
Being that I'm operating on only a few hours of sleep over the last couple of days, I'll cut to the chase. This experiment that you just went through should help reiterate the fact that your interface needs to be fine tuned so that the users can see and find the elements they need when they need them. For me, I'm a big fan of the concept of "less is more". As I'm working on a prototype, I make elements fight for their lives to get on the page. I attempt to keep things as basic and streamlined as possible. When you can get rid of a lot of the visual noise and concentrate on designing the flow of the form so that it guides the user where they should go, amazing things happen.
Keep this video in mind as you work on future designs so that your users will clearly see the "monkey in the middle". And if you want to hear more of this UI mumbo jumbo, make sure you come to BP214, BP216 and BP217 at the 'sphere! P.S. If you have an app that needs some help, bring it to Lotusphere and maybe someone can help get you started down the right path. Details in the next post.
Hello, my friends! Long time, no see. That's because my new employer has me signed up for so many training courses, I can barely come up for air! :-D One thing I can unequivocally guarantee...if you work for IBM, you will never be bored...haha!
Anyway, my next couple of posts will be asking for your help. I really think (and hope) that you will be able to come through on this one. Here's the deal. I am working on a new project and am looking to gather examples of really bad user interface designs. Now, bad color choices and related types of problems are pretty prevalent in Notes applications (and I certainly welcome those), but what I'm really hoping to find are those things that go beyond the surface. Do you have an application that is just incredibly hard to use for one reason or another? Is there a particular interface element used in a way that completely goes against its intended purpose? Basically, if the UI is poor in any way, I'm interested in seeing it. The worse it is, the better for me! :-)
Here are the ground rules:
1. All information you send me will be kept completely confidential. I'll credit you as contributing to the project if you'd like, but things will be modified so that the original design won't necessarily be identifiable when I show it.
2. Make sure you delete any company data from the application. Send me a clean database copy and populate it with some fake data if you can (just enough so we can see the problem).
3. If you want, go ahead and clean out any identifying company logos, names, etc.. If you don't want to do this, that's fine...I'll make sure I do it in Photoshop when I create my screenshots.
4. Send all submissions to firstname.lastname@example.org. Please use the subject "Bad UI Design Submission".
Basically, this project will be something that can be shared with the community and will be for educational purposes. The intent is not to point out bad developers or anything of the kind. I'm sure *ALL* of us can find some applications that we'd rather hide in the closet than let anyone see today. However, I think they'll be some great benefits that come out of this, so I really welcome and respectfully request your submissions. That's all I can say about it for now, but I think it will be fun.
If you have any questions about this, please let me know, either in the comments here or via e-mail. Thanks in advance for your help!!! :-)
One aspect of usability that I haven't spent a lot of time exploring here is accessibility. Depending on your company or industry, this is a subject that may or may not mean a lot to you. A simple definition of accessibility is that it is concerned with making all of the functions of your application readily available to as many people as possible, regardless of ability. This may take the form of a well-designed webpage that behaves properly when accessed by a screen reader device for a visually handicapped user or making sure that if you design a drag & drop feature that there is an equivalent way to carry out the action for a user that is unable to use a mouse. Certainly making your applications completely accessible can add an entirely new dimension of complexity to the design process, but you can start by taking small steps when you are working in your prototype phase (you *are* usingLFPs, right?). When you are working on an initial design for an application, take some time to consider any challenges various user types might encounter when working with your application. Then, try to figure out ways to mitigate these challenges while still providing a compelling experience for the majority of your users.
Let's take a very common example from Lotus Notes applications. Almost everyone can find at least one app in their environment that has views that utilize colored icons to denote some kind of status. Maybe it is a project tracking program and the adherence to the project schedule is represented by a red, green or yellow icon. Pretty standard, right, and easy to understand? Yep, most certainly...unless you are color blind. In this case, those icons might all look the same and without some other type of indicator, that user cannot determine which projects are in trouble and which are doing well.
How might we rectify this situation for our color blind user while maintaining our simple paradigm of using icons to denote status (which allows us to effectively use our screen real estate to show other important info)? One idea would be a slight redesign to use different shape icons in addition to different colors. Thus, our initial design becomes:
With this very simple tweak, we can still make effective use of icons to relay document information, still use color (which in this case is a powerful metaphor) and enhance the accessibility of our application for our visually challenged friend. Not a bad day's work for a small investment in time.
Accessibility is, as you would expect, a very broad topic and I've just scratched the surface with a simple example. What I hope to accomplish with this post is to get you thinking about the topic so it can be in the back of your mind the next time your start working on a design. Anytime you can overcome these small hurdles, your application is on its way to better usability. Good for you!
If you have a certain action, section, field, etc., that should only be accessible to a certain user/role, then please, please, please do not show that construct to someone that doesn't have the rights to do something with it.
I cringe every time I encounter a database with an "Edit" action button always visible when I know full well that there is security enabled and most users will click this button only to get an error message. It's really very simple...Spend the extra few seconds/minutes it takes you as a developer to write a hide-when formula to make sure that only people that can really edit the document see the button.
Did you ever want to include a little icon or picture directly next to a document in a view that you could click on to initiate an action? You see this on the web all the time, especially in the "Web 2.0" world. This tip will show you how to accomplish this within the Lotus Notes client. I think it's a pretty cool little trick and I hope you will as well.
Here's the scenario. Remember the Super Burrito Configurator? Well, one part of this (over the top) demo is the ability to construct your meal by dragging the ingredients to the burrito image. This generates a list, which is just a folder that you are adding new documents to. Since I'm using an embedded folder, I didn't want to pollute it with action bars, selection margins or other view riffraff. What we are looking for here is a nice, clean and obvious solution. Notes views don't provide many affordances. Unless you are trained in the software, you don't know that you can select a document, go up to the Actions menu and select Folder - Remove From Folder. Even if you know how to do it, who wants to??!!! It's too cumbersome. So, what I ended up with is something that looks like this:
Notice the icon with the word 'Delete' directly next to each burrito filing? Clicking on the icon does exactly what you would expect...deletes the ingredient from your burrito. In Notes terminology, it just removes the document from the folder. Pretty cool, eh?
The secret here is to take advantage of the view's InViewEdit event. When you click on an editable column, the code in this event will run. Since I'm just removing the doc from the folder, it's very simple LotusScript: I don't have to mess with the various cases that you typically encounter with InViewEdit and I don't have to worry about doing any kind of validation. All that matters is that when the user clicks the column, the code runs. Here it is:
Sub Inviewedit(Source As Notesuiview, Requesttype As Integer, Colprogname As Variant, Columnvalue As Variant, Continue As Variant)
Dim doc As NotesDocument Dim caret As String
REM Get the CaretNoteID - exit if it does not point at a document caret = Source.CaretNoteID If caret = "0" Then Exit Sub
REM Get the current database and document Set db = Source.View.Parent Set doc = db.GetDocumentByID(caret)
REM OK...we can ditch it Call doc.RemoveFromFolder(Source.View.Name)
This LotusScript was converted to HTML using the ls2html routine, provided by Julian Robichaux at nsftools.com.
To configure this for your own use, just follow these steps:
1. Add the above code to the InViewEdit of your folder
2. Select the column you want to use for the action and set it's properties for "Display values as icons" and "Editable column"to true
3. Set the value of the column to the icon you want to use (either the number or the name of an image resource)
4. Bask in the glory as your users tell you how awesome you are! :-)
That's all there is to it. This is another seemingly trivial but very high value technique. It allows you to simplify the UI greatly and follows the rule "don't make me think!" to the letter. Of course, you're not limited to just removing the document from a folder. Basically you can code anything you'd like in the InViewEdit. How about marking the document as a favorite? Adding the author to your address book? There are probably a lot of cool uses for this idea. Now it's up to you to try it and figure out where it might work for you. If you use this technique in an innovative way, please let me know so I can share with everyone.
There are so many packaged products that have this problem, but it's pretty sad when it's a company that obviously has a usability staff! :-)
If you start out frustrated even opening the box, the user experience is already tarnished. Try to remember this fact, as it is true for what we do as well. In our case, it might be the initial way your customer contacts you, the first meeting you have with them, your website, etc. First impressions mean a lot...make yours the best you can!
Hive Mind: What's Your Favorite User Experience Tip?
Hello Friends! I thought it would be fun to try a little experiment here and develop a group writing project that would allow us to define best practices around the user experience using the Lotus Notes client. While I don't believe in absolutes, there are many ideas which will almost universally improve the user experience. Let's see if we can document some of those.
Here's what I propose. Like all the things I work on, this is pretty simple! ;-)
1. Pick one (and only one) idea or technique that you'd like to represent as a user experience best practice. What we are looking for here is to focus on the Notes client, as there's tons of stuff out there regarding UX best practices for the web. (Many of those are applicable in any software environment, actually, so it's good to be aware of them).
2. Share this idea via your blog, leave a comment here, or send me an e-mail. I'll create a special area (perhaps a wiki?) where this information can be consolidated after people have had a chance to comment on the various concepts.
This will be a community controlled effort to get the initial entries together, so if your entry generates a lot of "boo hiss", we'll choose to leave it out. If we get enough people to participate, we'll end up with a nice little resource that the entire community can use.
I believe a focus on the user experience from the standpoint of the everyday Notes developer is even more important now than ever before due to the efforts that IBM is putting into this area. The last thing we want to do is expose our ugly old apps in the beautiful new Notes 8 shell. It will be like "putting lipstick on a pig"!!! Perhaps this group resource will be a place where developers can go to draw inspiration for their next project.
Along with the "Best Practices Guide for the User Experience", I was thinking of creating a "Lotus Notes Interface Gallery". Think of this as a place to show off your best work, again with the goal of providing inspiration (and perhaps some bragging rights) to other developers who might not be comfortable in anything other than the 3-pane UI model. For all its warts, there are some excellent examples of Notes UIs out there, and I think it would be cool to get them all together in one place. What do you think? A dedicated sub site here or something more generic, such as Flickr? Let me know your thoughts and feel free to send me submissions.
Well...This is a community all about collaboration and it's what we do best. So, please, if you are interested, consider playing along. This could be fun AND educational! Cheers...
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... ;-)