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.
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.
Implementing A Tag Cloud In The Lotus Notes Client
Welcome back. It's been awhile. I'd ask you why you haven't visited or called lately, but I know...it's me. I haven't been giving much to this relationship lately. I'll try harder...I promise. How about starting with a new post about creating a tag cloud in a Lotus Notes client application? That sounds good? Great...thanks for giving me a second chance! :-)
Way back at Lotusphere 2009, Nathan and I delivered a presentation on Web 2.0 design patterns for Lotus Notes. He focused on the web side of things (with XPages) and I worked on the client UI side. Unfortunately, some technical difficulties got in our way and the session wasn't nearly as good as it could have been. However, the content is still worth digging into, so I thought I'd start out with one that is useful for injecting the idea of topic popularity into your application: The Tag Cloud.
I'd guess that most people have at least seen a tag cloud by now, given that it is a pretty common Web 2.0 pattern. A tag cloud is used as a navigation mechanism to allow users to browse information and see at a glance what content is most popular or prevalent in an application. A tag cloud is simply a list of tags (be they user added or generated from categories) where the physical size of the tag represents the weight (frequency) of that information within the application. An important aspect of the tag cloud is that you can click on a tag and this action will filter the data list to show only the content with that tag. Here's an example from one of the Lotus products, Lotus Connections:
Tag clouds can be very useful in situations when a user wants to discover information rather than search for it. I've gone on and on before about the fact that most business applications are such that a user has a targeted objective when they use the app, so the UI should be designed to facilitate getting them to the info they need as quickly as possible. There are certain classes of applications, however, where browsing of information is more meaningful. A discussion database is a great example of this, as are apps such as product reviews, policies and procedures and so on. When discoverability will add value to your application, then a tag cloud might be a good choice for a UI component.
Before we jump into the implementation, let me put forth a few caveats. First, when I was initially coming up with this, I went through about four different methods of creating a tag cloud. These methods ranged from quite simple (like I'll be showing you here) to insane hackery. While it's pretty easy to build a tag cloud on the web and there are tons of code samples to do so, it was a bit of a challenge to implement one in the Notes client. Each of the different techniques I tried had strengths and weaknesses. I decided to go with the method shown below because it was the most straightforward and will work in R6 and above, so it's not limited to the latest and greatest version of Notes. It's not elegant, but it works. I'm a fan of clean, elegant design, but sometimes it's necessary to create something less than beautiful behind the scenes to make the end user experience better. As long as you are not creating a maintenance nightmare, I think it is OK that we work harder so our users don't have to.
The way I approached this technique was to make use of the category field in an existing Notes database. Exposing existing categories as a tag cloud is a very easy way to get started and introduce this functionality to your users. Personally, I find that tag clouds work best when the number of entries is not overwhelming. They do take up a lot of valuable screen real estate, so you'll need to make the call as to whether they add enough value to justify use or not. Of course, the ideas presented here can be applied to any data captured in a discrete field on your documents.
Aside: I would be remiss if I didn't point out that there is a Tag Cloud component available on OpenNTF that you can use in a Composite Application. With this component, you can add tag cloud functionality to your application within minutes. There's a good tutorial on doing so here.
The first step in building the tag cloud component for the Notes client is to create the view that will be used to get the tags (categories). Here's a screenshot showing the view in my demo database.
The first column includes the count of all the tags in that grouping, which I find useful to display along with the tag cloud in some cases. We'll use this view to lookup the tags and display them in the tag cloud.
The next thing we need is to create the form that will serve as a container for the tag cloud. I decided to use a form as it gives the flexibility of having the tag cloud generated on the fly or via a process such as a scheduled agent. I'm also trying to make these techniques easy for newer developers, so the form and field idea works pretty well. Because we need the tags to be clickable, we need some sort of hotspot on each one. This could be likely by accomplished by using Lotusscript or a third-party product like Midas to build the tags in a rich text field and then put links around them but this seemed a little complex for my tastes. Thus, I decided to implement the tag cloud as a series of fields. Each field holds a single tag and then I created an action hotspot around each field. Let's break it down bit by bit:
Click to enlarge
First, the top of the form houses some computed fields that are used to lookup the tags and the quantity each of the tags. These values come directly from the tag cloud view.
Next are the various tag fields themselves. Now...before you start going off...I know that this is cumbersome to build the first time. However, I decided to strike a balance between functionality, ease to maintain and ease for the developer to understand, so it is what it is! :-) If you decide to use this technique, it would be a good idea to try to gauge how many tags you have before you build it. My personal preference is to limit a tag cloud to no more than 40 or 50 tags (I like less). Beyond that number is just too much visual noise for my taste. However, this could expand to as many fields as you want to create.
The field values themselves are populated in the PostOpen event. This event holds the meat of the code, as it implements the tag cloud algorithm to allow us to determine how large (from a font size perspective) each tag should be. There are variety of these algorithms available on the web, and I won't belabor them here. For our purposes, just know that I selected a common one and implemented it in formula language. The code loops through each value of the num_CategoryTotals field, determines how many entries there are for that tag and then uses that number in the algorithm to set the font size, plugging the value of the current tag into the txt_Tag# field that corresponds to the counter in the loop. If you'd like to use a different tag cloud algorithm, just substitute your code as necessary.
The final part of the equation is to add a hotspot around each tag field. This hotspot will filter the view that you are displaying to the end user so that it only shows the given tag (category). In order to do this, we make use of the @SetViewInfo command. If you are not familiar with this command, it was added in R6 and allows you to display only documents from a given category in a categorized view. Armed with this tool, we open the view in question, make sure all the categories are expanded (or else you can end up with what appears to be a blank view) and then perform @SetViewInfo, using the given tag as the filter string.
One other note: You may want your tag cloud to have different colors. Not only does this provide visual interest, but it also can provide another clue as to the relative weight of a given tag (i.e. tags with the same color have close to the same number of entries). You add color in one of two ways. You can set the color values using formula language in the PostOpen event, or you can just apply color to the individual tag fields. The advantage of the first option is that it does respect the concept of relative weight of tags, but the disadvantage is that you are limited to the 15 colors allowed in @Command([TextSetFontColor]). With the second option, you can use any color you want, allowing you to make the tag cloud fit better with the design of your application. What you lose here, however, is the idea of relative weight since you are randomly choosing the colors. As always, it's a judgment call. Use whatever concept works best for you.
Once you put all of this together, all that is needed is to drop your tag cloud form into a place that makes sense. In most cases, a tag cloud will be most compelling when included alongside a view, so if you are building a frameset with navigation elements in one frame and a Notes view in another, the tag cloud should be included in one of the navigation frames.
When complete, the generic, non-styled version looks something like this:
But a little more work integrating it into the design of your application can give you something like this:
Now that is all said and done and I know what you are thinking: "Give me the code and sample database already!". OK, OK. Here we go:
I've included two downloads below. One is the complete design pattern database that was used at Lotusphere. This has all of the code and you can see how it was customized for the specific database in question. (This is a database that is about 10 years old...created in R4.6 or R5, I think, and I reskinned it for use as a demo). The other download is the very generic implementation of the tag cloud with just the tag cloud components in it. The idea is you should be able to grab these design elements, throw them into your database and be up and running with a tag cloud in a few minutes. I've included the instructions to add the tag cloud to your application in the Using This Database document. Download the database and dig in to give it a try.
I know there are a lot of improvements that can be made here, but my hope is that this gets the ideas going. I haven't seen an implementation of a tag cloud in the Notes client from the blogsphere yet, but I can't wait to see what you all come up with based on this skeleton. Please let me know and if you'd like, I can share your results here.
When I'm building a new UI or composing a document to send to an audience, I like simple elements that make a big difference in the final presentation. I thought I'd share a trick that I use to add whitespace to designs when using graphics with wrapping text in Lotus Notes.
If you've not tried it before, first let me point out that you can paste or import an image into a Notes form/document and set the properties of the image so that text can wrap left or right. This is analogous to using floats in CSS on the web.
While this can spice up your formatting quite a bit, in the Notes client the text butts right up against the graphic, so this doesn't look particularity nice. By way of example, the other day, I wanted to send my latest blog post to some internal folks through Notes and I wanted to retain the formatting (as close as possible) to my web entry. Thus, I made use of the text wrap property. This ended up looking like so:
Notice the lack of whitespace around the photos. Here's a close up to show what I mean:
So how do you fix this? Simple really. Most elements have a Border property which can be manipulated. This doesn't necessarily mean you have to have a physical line around your element. A border can be used to emulate padding. If an element has a border, you can also define the space between the inside border and outside border and between the outside border and the elements outside of that. Click the drop down in the border properties box to choose between the border thickness, the inside spacing and outside spacing.
For the purpose of this e-mail, I thought a spacing of 7 looked about right, so my properties box was set accordingly
This quick update produced the following results:
and close up once more
A very subtle effect, but a powerful one. Remember that whitespace is very important for guiding the eye and providing a feeling of space. It's a little thing that people may not be able to articulate if you ask them to point it out, but I guarantee that they'll think the option with good use of whitespace looks better ever ytime. Whether it's really true or not, if it looks better, people will think it is better. When dealing with the UI, often perception is reality. I hope this helps. Cheers!
A blog post entitled "Holy Cow, This Is Cool Or In Which I Introduce A New UI Technique But Give It A Vague And Flavorful Title to Game People Into Coming Here From Planet Lotus Since No One Really Reads This Interface Stuff"
Hi All...I always seem to come up with these posts at times that no one is around, but what the heck. Lotusphere is almost here and I'm lucky enough to be presenting once again (more on that later). As I was driving to a customer's site the other day, I thought of this technique and after playing around for a few minutes, I found that it works great. If you like it, consider it an early Christmas (Festivus, Hanukkah, insert holiday of choice here) gift.
I really love many of the UI patterns that have become popular in "Web 2.0" applications. Among these, one of the techniques that you see quite often is that of the "Fade In/Fade Out" element. Let's say you want to display a status or error message to a user after they enter an incorrect value. Sure you can just use a hide-when and make the text appear or pop up a message in a dialog box. But that just isn't sexy. You can add a little spice to your app by applying this modern looking UI device. First, let's see it in action, then I'll explain what's going on.
Now...that's the Lotus Notes client you are looking at, not a browser. While it's a very basic effect, it enhances the user experience in a nice and subtle way. It helps draw attention to the fact that there is a new element on the page and does so in a way that is less jarring than a pop-up box or instantly having the message appear on the screen. The beauty of this technique is that it is very simple to implement in your application. Here's how.
The key to this technique is the versatile programmable tabbed table (I continue to find new uses for this design element....I love it!). What I did is create a tabbed table and set the text and background colors to get progressively darker for a fade in effect. Then, using script, I simply switched from one row to the next on a timed interval using Sleep to pause the necessary amount of time.
For purposes of this example, I hard-coded everything, but after going through the steps, you should see how easy it would be to modify this so it is dynamic. The picture below shows the six rows that I used for the table. I selected a base color for the final display box background and then used lighter shades of that color for the previous rows. I did the same thing for the text in each row. I haven't really thought of any hard and fast rules here...just play with it until it looks good to you.
Hint: I find it easier to do the formatting for a tabbed table as just a standard table at first, then switch it via the Table Rows property tab.
As you may recall, you can programmatically switch rows in a tabbed table by writing a single formula line such as FIELD $DisplayTable1:= "4", where DisplayTable1 is the name of the table as defined in the Table HTML Tags properties and 4 is the name of the row.
You can also change the row via script, which is what I did in this case. I resorted to using LotusScript since it provided me with a facility to directly control how much time I wanted between each row change. If you are going to use LotusScript to do the row switching, make sure you add a field to your form that is the same name as that of the table (e.g. $DisplayTable1), otherwise you'll get an error when you try to set this field in your code.
Once you have the programmable tabbed table setup and formatted as you like, you just need to write the script to display the table rows to simulate the fade in effect. If I was doing this in a production app, I would probably hide the table until I needed it, fade in to the message and then fade out when the user dismisses it. Thus, the code would look something like this:
Dim workspace AsNewNotesUIWorkspace Dim uidoc AsNotesUIDocument
This LotusScript was converted to HTML using the ls2html routine, provided by Julian Robichaux at nsftools.com.
Notice here that the first thing I am doing is setting a field called ShowMessage to "1", which is just a field I use to control the hide-when properties on the table. Then, I set the table to row 1, refresh the document and sleep for .15 seconds, switch to the next row, sleep again and so on until the final row is revealed. To fade out, just repeat the steps above in reverse. That's all there is to it. I told you it was easy.
In case any of that was unclear, I've created a sample database that you can download to deconstruct the technique. It is simple and elegant, which you know by now is my favorite kind. I hope you can find a use for this in your applications.
Now...I mentioned before about Lotusphere. Did you like that technique? Do you want to learn even more "Web 2.0" UI goodies? Well, it just so happens that I'll be teaming up once again with my friend Nathan Freeman to present AD212 - 10 Web 2.0 User Interface Patterns for IBM Lotus Notes and XPages. In this session, we'll be taking a look at 10 popular modern UI patterns and showing you how to bring them to the client and to XPages. I'm excited about how it's coming out and I hope you'll drop by to check it out.
In addition to my session with Nathan, I'm very pleased to report that I'm teaming up for the first time with Tom Duff, aka Mr. "Now I'm published in a popular CIO.com article" (go read it...it's awesome!). We're going to be presenting BP108 - Getting To WOW...Interface First Design for IBM Lotus Notes Developers (it's also being repeated in case you can't make the first session). This is an updated version of some of my past presentations and I'm excited about it because Tom will bring his unique insight into the process of moving from a code-focused orientation to a more holistic one. Please come by if you can (and we'll have some goodies to give away as well! :-)
That's all for now. Signing off so I can work on more Lotusphere stuff. I hope you all have a fantastic holiday and very happy New Year!
Flashback: The Low Down On Low-Fidelity Prototyping
Note: This is a repeat of one of my more popular articles. It is reprinted here after several requests. Since I have a lot more readers now than I did when originally posted, I thought it would be a good time to recycle it. :-)
You don't have to be on this site for very long before you'll start picking out some common themes. Two of the topics that I am very passionate about when it comes to the development process are low-fidelity prototyping and usability testing. I truly believe that every developer (no matter what their preferred technology) can reap enormous benefits by adding these two simple techniques to their development methodology.
On the most recent Taking Notes podcast, I mentioned I have some articles about usability testing coming up. Well I do, but I thought it might be a good idea to cover the first of my two 'secret weapons', since usability testing actually follows as a logical extension of low-fidelity prototyping. With that, let's first define what low-fidelity prototyping is about. Due to its RAD nature, most Notes developers are very familiar with the concept of prototyping. In the case of low-fidelity prototyping, the word 'fidelity' refers to the level of detail in the design itself. That is:
Low-Fidelity = Quick & dirty hand drawn screens
High-Fidelity = Polished design or high-quality screenshots/mockups
Another name for low-fidelity prototyping is "paper prototyping" and perhaps this name more fittingly describes what you use in the process. I prefer low-fidelity prototyping because it sounds more impressive, and if I were a consultant, I could probably charge more (haha...OK...only kidding!). The purpose of the low-fidelity prototype is to allow you to design the interface of your application before you focus on anything else. Some developers think I am committing heresy when I say this, but I believe without a doubt that you can design a better application if you build the interface before you write any code!
One of the first benefits that low-fi prototyping brings you is the ability to talk to a customer in concrete terms very early on in the project. When they are giving you requirements, customers usually have very nebulous ideas about what they are actually looking for or what they are going to get. It is very powerful to be able to return to the customer shortly after the initial meeting with a physical object that they can review, manipulate (by turning pages), etc. This initial prototype may be completely wrong, but it gives you a common platform from which you can continue your discussions about the application. I think you'll be surprised at what additional information you uncover so early on. There are several other benefits that low-fidelity prototyping brings to the design process, but first let's take a step back and talk a bit about how you build one.
Perhaps one of the neatest things about low-fi prototyping (that's what the cool kids call it) is that it is so easy to do...and dare I say...a lot of fun. The tools of low-fidelity prototyping are all those things you used in kindergarten; paper, pencil, markers, crayons, scissors, glue sticks, etc. The key to low-fidelity prototyping is drawing out enough detail to allow the customer to figure out what is going on, but no more. The low-fidelity prototype is not meant to be polished. It's just a 'rough draft' of your screens. A lot of great work in design and engineering was initially conceived on the 'back of an envelope' and the concept is the same here.
To get the most benefit from this technique, you need to draw out all of your interface elements. This includes screens, menu items, dialog boxes, etc. Place only one element on a page (e.g. if you have 5 dialog boxes, use 5 sheets of paper, one for each dialog). This makes it easier to manage your design, especially as you work through multiple iterations. That's really all there is to it!
As you are beginning the work on your low-fi design, remember that this is the ideal time to 'think outside the box'. Try to forget the constraints of your development platform and instead focus on how you can design an interface that will be clean, efficient and easy to use. If you have the luxury, I think the ideal state is to stay technology agnostic. Design the interface, figure out what functionality is needed and then decide on which tool is the right one for the job. You can temper this with good judgment, of course. If you know you are building an application in Notes, don't design an element that you absolutely know you can't use in the client. However, some of the best interfaces I've made were initially born out of low-fidelity prototyping, followed by an exclamation of "There's no friggin' way I can do that!" A little perseverance and a lot of experimenting in this regard can pay off big time, though, so give it a try. The worst that can happen is that you fail, learn a lot from that, and then move on to plan B.
Once you have completed your first low-fi iteration, schedule some time with your customers to discuss it. See if they can understand the functionality without you explaining it to them. Are there glaring errors that are immediately evident or are they just bringing up subtle points? Make sure to take as many notes as possible, trying to capture everything the user points out or alludes to. You can often find important information in these notes...things the customer initially forgot to tell you, details on how computer savvy the user base is, etc.
So...You've built your prototype, met with your customers and got a couple of suggestions for changes. Time to go write some code, right?! Whoa, there partner...not quite yet. Unless you absolutely nailed it on the first try (probably not), it's time to build another iteration. On average, I'd say you'll build about three low-fi designs in a typical project. Each time, you'll refine and meet with your customer, coming closer to the final interface with each pass.
Let's return to discussing benefits around low-fi prototyping, since this is one of the stages where you really see a payoff. One reason low-fidelity prototyping works so well is due to the psychology of how we perceive quality. A user looking at an actual application on the screen is generally less apt to point out flaws, even if you only invested a little time in it. They think to themselves, "Gosh, he's already got something ready for me. I guess I can live with this, even though it's not exactly what I want." The customers tend to censor themselves, since they think you've invested time and money in the design. At this point, you might be thinking "Not my users...they hate everything and tell me so!", but most people will do this, just to varying degrees. Users generally have no problems, however, when you throw a hastily drawn piece of paper in front of them. When it looks like you had a little kid whip something together, the customer will definitely let you know what they think! :-) In fact, I suggest a little experiment. When you go into your low-fi meeting, strategically place some pens, pencils, crayons, whatever, in an area that the customer can readily access. I'll bet that when you set the prototype in front of them, they reach for one of those implements and start marking away. Let them! This is valuable, as it helps you see what they really want. It also gets the user emotionally invested in the design, which in my experience leads to increased satisfaction at the end of the project.
As developers, we benefit from low-fidelity prototyping as well. It may sound like this process adds time up-front and you're right...it does. However, once your prototype is pretty well finished, you've got a great plan for development. You won't be sitting there staring at a blank canvas, wondering how to start. Instead, the low-fidelity prototype provides great clarity and allows you to concentrate on the next important part of your process, actually writing the code. Also, since we've avoided code until this point, we've probably saved time and money. Often, the choice of interface elements we use dictates the most efficient path we take coding wise. Any time you start development by writing code puts you in danger of having to back track or rewrite in order to address UI concerns. Hopefully, you can see that capturing the specifics of the UI up-front helps mitigate these risks.
The definition, increased communication and clarity that low-fidelity prototyping can bring to a process is highly beneficial by itself, but it becomes infinitely more powerful when combined with our second 'secret weapon', usability testing. That's right...you can actually test your application using the paper prototype (how cool is that?) We'll explore this technique in a future post.
For now, let me leave you with a call to action. Give this process a try on your next project. It's certainly not hard and I think you'll find it very powerful. If your customers (or most likely your boss) look at you a little weird, be honest with them. Explain why you are doing this and the possible benefits (hint when dealing with the PHB* --> "It saves money!!!"). Let them know that it is a new concept for you as well and that you'll learn together. The customers will appreciate your openness and will most likely be willing to give it a go. My guess is that after the project, you'll be doing a lot more low-fi work.
Overall, low-fidelity prototyping is a super technique that I use all the time. I hope you find it as compelling as I do. Good luck!
Balsamiq Mockups...A Very Cool Tool For Building Prototypes
As long-time readers know, I'm somewhat of a zealot when it comes to singing the praises of low-fidelity prototyping. Over time, I've found that it allows me to get to the best possible user interface faster than any other method. While I love breaking out the crayons, markers and paper, I do admit that it sometimes becomes more time consuming than I'd like if I have to keep redoing a certain screen. This is where I see a computer-based tool being very helpful.
In a past post, I introduced you to using electronic tools to build a prototype. Thanks to an e-mail I received from a reader (Cheers, Miguel), I've found another prototyping tool that I think could be *the one*. From what I've seen, it's full featured, very easy to use and allows you to create interface mockups in a flash. It's got a funny name, but the story behind it makes it quite apropos. Check it out...it's called Balsamiq Mockups
I'm not going to go into details on the features here, since the elegantly designed Balsamiq website already does that. I do, however, want to point out some things that make it killer:
* It's got a web UI as well as a desktop counterpart if you want to do offline work.
* The hand-drawn elements are well done and plentiful. There's a control, window or container for almost every UI situation you can think of.
* You can export the end result as a PNG or XML file.
* It just works.
If you've ever considered building low-fidelity prototypes but were put off by the idea of using analog tools, I'd definitely recommend giving Balsamiq Mockups a try. You can use the web interface directly from the site. Hopefully, I'll have the opportunity to test drive the desktop based version soon. If so, I'll be back with an updated review.
OK...so what are you waiting for. Go forth and draw! :-)
It seems some folks liked my idea from last week, especially the example screenshot showing a drop down menu in this "universal toolbar" area.
I received a comment and a few e-mails asking how this was done. Well...I actually wrote this up (along with a sample database) a couple of years ago, so today's show and tell will be a cheat, as I am just going to link you over to that entry. With that, here you go. Enjoy.
Editor's Note: The sample database that is available for download also includes all my experiments using layers to create cascading menus. Remember...Lotus Notes is like an onion...it's got layers! :-)
SnTT: Add A "Universal Toolbar" To Your Lotus Notes Applications
Hey, look at that: A Show-n-Tell Thursday post. Woohoo! OK...I've got to think up a better/more descriptive name than "universal toolbar", but I'm creatively challenged today. At least I got a post out...geez. :-)
If you think about most of your applications, there are probably certain functions that are executed more than anything else. Perhaps it is a particular search mechanism, running a certain agent or navigating to a given document. Whatever the most common action is, do you make it easy for your users to get to? By easy, I mean is it always available or at least one step away? If not, you might want to consider using the universal toolbar technique. It's a simple and elegant solution for many UIs.
Here is one example. In this application, the most frequent activity is to open a particular document. There are several different parts and areas to this application, but often the user needs to quickly get to one of the core documents by the key value (in this case a part number). In a typical Notes application UI, a user would have to navigate to the view that contained the document in question, then use the "Starts with..." quick find function to jump to the document and then double-click on the document to open it. This is at least 3 steps and for a very frequently used activity, I think this is too much. Instead, my universal toolbar includes the ability for the user to enter the Part Number and open the document directly, no matter where in the application they are.
As you can see from the screenshots, it doesn't matter where the user is in the application, they always have the ability to enter the Part Number and the application will open the document. This saves the users tons of time and they love it!
To do this, I add a small frame into the application frameset. This can be positioned anywhere really, but I find it works well near the top or under the header. This frame becomes the container for your universal toolbar, which is usually a form containing the functionality you want to make available.
If you look carefully, you'll also notice I use a border caption on the universal toolbar frame so that it can be hidden if desired, freeing up that screen real estate.
Here's another example of using the universal toolbar concept in an application. In this case, I gave the users drop-down navigation. Space was at a premium in this application, so we wanted to remove any links to the left or right side of the screen.
One other way I've used this is to allow the user to quickly add new documents without opening a form.
So that's it...pretty simple but very effective. Everytime I've added this functionality to an existing application, I've received rave reviews from users and thanks for saving them time. Give it a try in your apps and let me know how it works.
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.
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.
Have you ever wanted to spice up a view a little by adding abstract information to it? That is, to include some of the text of the document in the view itself so the user doesn't have to open it to determine if it is worth reading? This is pretty simple to do using the @Abstract formula.
@Abstract allows you to abbreviate the content of a field in a Notes document. What I find cool is that it can also work on Rich Text fields. Now, @Abstract is very powerful and can allow you to do some interesting transformations with information in a field, but for the purposes of exposing some abstract information in a view, we'll just use the simple stuff.
In order to maintain good performance in your application, you shouldn't use @Abstract in the view itself. Instead, create a new field on the form in question in order to capture the abstract information. You can then refer to this field in the view column. Let's say you want to add this functionality to a document library. Open the 'Document' form and add a new field called "BodyAbstract". This should be a computed text field. The formula for this field would be something like:
As used here, this will capture the text of the "Body" rt field, trimming out whitespace and grabbing the first 1000 characters (Check out the help file to see how you can enhance @Abstract with additional keyword parameters).
In the view, in order to allow the user to decide whether or not the abstract should be visible for a particular document, I made the "Subject" column categorized, then included the abstract in a regular column. Here's what it looks like in design mode:
And here it is in action:
Click to enlarge
@Abstract is useful for many purposes, and this simple technique exposes just one of those. I think this idea makes sense for a lot of document-based repositories and as a bonus is really easy to implement.
Quick tool tip of the day: If you have a (ahem) rounded corner fetish but aren't so handy with Photoshop or Paint Shop Pro, there's an online tool that will allow you to quickly add rounded corners to any photo or graphic.
Just head to RoundPic.com and either select a photo from your computer or enter in a URL. Click the "Round It!" button and your anti-aliased, rounded corner image will magically appear. You can even select the amount of rounding you want and the background color that will define the space "behind" the image. A downloadable image is then made available for your use. A perfect solution from a website that focuses on one common problem. Enjoy!
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 email@example.com. 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!!! :-)
Hi All. Sorry for the long absence. I'm an official IBMer now and I've been heads down learning the ropes. It's been intense to say the least and it's only been a few days! :-)
Today, I wanted to head back up to the 30,000 foot level and discuss a little about Design (yes...a capital D...because it's so important) and how it is a subject you can learn about from many different sources.
It's a pretty well-known fact that we ("we" in this case meaning humans) enjoy beautiful things. We admire the "beautiful people", we seek out beauty in museums, at the symphony and in the library. This search for beauty applies to all aspects of our lives, including our work. People enjoy tasks more when they get to work with beautiful things. An elegant new pen may provide you with inspiration to sit down and write in your journal. The Michael Graves designed toilet bowl brush just might make that cleaning job a bit more bearable. In the same way, that well-designed accounting application that you built has the potential to turn a mundane monthly reporting project into a job that the accountants don't dread so much anymore.
If we take it for a given that people like beautiful things, then how can we logically extend this fact to make our applications better? One of the interesting things that interface designers have figured out is that a user's perception of the quality of an application is proportional to its adherence to good design principals. That is, things seem to "work better" when they are well designed. This has profound implications in our work and I think this emphasizes why design of the visual aspects of our applications should not be an afterthought.
I have found in the past that computer people tend to be less concerned with how something looks that the general population (yes...I am using a blatant stereotype here ;-) In reality, we should strive to become well-versed in the hows and whys of good design because we're actually building stuff people have to use. Apple is a company that has embraced this idea. They certainly did not invent the mp3 player, but many people think they did. They set the standard in the category by building a beautifully designed device with an interface that is just a pleasure to use.
Beauty in an application does not necessarily have to be skin deep either. Just having a pretty interface won't help if the users have a hard time actually *using* the program. Thus, in my mind, beauty in application design is comprised of an attractive interface as well as a simple and intuitive user experience. Gmail comes to mind as a perfect example of this. It's not necessarily a work of art in visual terms (although I like the clean design), but the user experience is so well thought out that I can't think of going back to another e-mail program for my personal accounts.
All of the above is just a long, roundabout way of suggesting that if you are not already concerned with the aesthetics of design in your applications, you should start planning to head down this path. I've said it several times before, but it bears repeating. These ideas become even more important as you move your company to Notes 8 (why are you waiting? It's real and it's spectacular!) This is a beautiful environment (I *love* saying that about a Lotus product), but your old way of building apps will still make them look like old apps unless you start formulating a way to build a truly modern design.
So, if you've never fancied yourself a designer, how can you start down that path? One thing I recommend is looking for ideas all over the place. Subscribe to a magazine about interior design or fashion. Watch design shows on HGTV (guys...your wife will love this). Observe the form and function of things you work with everyday, such as your microwave, vacuum cleaner and TV. Note what features you enjoy using and those that annoy you. If you are so inclined, get a nice hard-bound notebook and keep a design journal, adding notes about your user experience with different products, clippings of things you like from magazines, etc. Just the act of doing these exercises will start to enhance your knowledge of good design and will train your eye on what to look for. Then, armed with this newfound information, you can start enhancing the design of your own applications. Even small, incremental design improvements will make a big difference to your users. I've received many testimonials from other developers that speak to this fact. A focus on beauty in your applications is a direct reflection of your caring for the user and remember, that's why we're all here. Now go on and get out there...Help make the world a more beautiful place. (And start using Notes 8, will ya? ;-)
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.
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... ;-)