Thursday, October 16, 2008

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.

Labels: , , , ,

permalink | leave a comment

Thursday, December 27, 2007

SnTT: Using @Abstract To Enhance A View

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:

@Abstract( [TextOnly]:[TrimWhite]; 1000 ; "" ; "Body" ).

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.

Labels: , , , ,

permalink | leave a comment

Friday, December 21, 2007

SnTT: A Simple Notes Based Document Rating Idea

Today, I wanted to whip up a simple document rating system that could be used in the Notes client. We see these all the time on the web. Netflix, a site I use regularly, has a nice implementation, as do many others. Jake showed us a nice version using Domino just recently too. I wanted to come up with a pure Notes solution, so I decided to make use of the editable view column property to accomplish this and it turns out it is very easy. I'll refer you back to this post, where I first discussed the concept of using an editable view column to perform an action. Before I review the specifics of the implementation, here's a quick movie to see how it works.


Click for animated demo


This is just a first pass, but I can see that this could be very handy. Basically all that is happening is that we are checking which star (column) is being clicked in the InViewEdit event. Then, we're equating this column to a value, which we add on to the total votes count to date divided by the number of votes. Then, in the final step of the InViewEdit code, we write the new rating value back to the document. I even added a simple check to make sure the user doesn't vote more than once.

Let's break it down step by step:

Step 1: Add columns to your view. I created a separate column for each star, since I want to know explicitly which one was clicked. Set the column to be editable and set it to "Display values as icons".



Step 2: The column value checks the current rating and based on the position of the column determines if it should show the filled or unfilled star.

@If(num_Rating >= 1; "star_red"; "star_open")

Step 3: Add the code to the InViewEdit event. I've included a bunch of comments so you can see what I was going for


Sub Inviewedit(Source As Notesuiview, Requesttype As Integer, Colprogname As Variant, Columnvalue As Variant, Continue As Variant)

Dim session As New NotesSession
Dim db As NotesDatabase
Dim doc As NotesDocument
Dim caret As String

'Get the CaretNoteID - exit if it does not point at a document
caret = Source.CaretNoteID
If caret = "0" Then Exit Sub

'Get the current database and document
Set db = Source.View.Parent
Set doc = db.GetDocumentByID(caret)

'Check if user already voted by looking if the user's name is in the nam_UsersRated field
'This is just one possible approach. Not sure how this will scale...might want to create a
'new doc in the backend that just records the user's vote for this doc. Have to explore...
Dim alreadyRated As NotesItem
Dim check As Variant
Dim currentUser As String

currentUser = session.UserName
check = Evaluate ( |@IsMember("| & currentUser & |" ; nam_UsersRated)| , doc )
If check(0) = 1 Then
Messagebox "Sorry...you've already voted for this document"
Exit Sub
End If

'If we got this far, the user hasn't voted yet, so we'll take their entry
Dim numRatings As Double '# of users who have rated doc
Dim voteTotal As Double 'numeric total of votes
Dim newRating As Integer 'the new rating for the doc (1 to 5)

numRatings = doc.num_NumberOfRatings(0) + 1
voteTotal = doc.num_VoteTotal(0)

Select Case Colprogname(0)
Case "Star1"
voteTotal = voteTotal + 1
Case "Star2"
voteTotal = voteTotal + 2
Case "Star3"
voteTotal = voteTotal + 3
Case "Star4"
voteTotal = voteTotal + 4
Case "Star5"
voteTotal = voteTotal + 5
End Select

newRating = Round((voteTotal / numRatings), 1)

doc.num_Rating = newRating
doc.num_VoteTotal = voteTotal
doc.num_NumberOfRatings = numRatings

'Add the user's name to the list of people that voted
Set item = doc.GetFirstItem( "nam_UsersRated" )
Call item.AppendToTextList( session.UserName )

Call doc.Save(True, False, True)

End Sub

This LotusScript was converted to HTML using the ls2html routine,
provided by Julian Robichaux at nsftools.com.


Voila!



Of course, before you implement something like this, you need to think through the implications of it in a production database. Do all users have the ability to edit documents? If not, perhaps you could use stub documents instead. Also, do you want to give the users the ability to see their vote vs. the actual vote? All of these things can be done...this is just the tip of the iceberg.

While this is really rough and I can think of several enhancements to be made, please feel free to download the sample database if you want to play around with it. If you actually use this technique or enhance it, please let me know...I'd be interested to see it.



Have a great holiday everyone!

Labels: ,

permalink | leave a comment

Wednesday, July 18, 2007

OK...Bar Charts In Views...Last Time (I Promise)

Wow...little did I know that posting such an innocent little tip about bar charts in views would spark all the great collaboration between everyone in the community. I made a faux paux in my original post by referring to my technique as Gantt charts while in fact they are really just bar charts. Luckily, this inspired Nathan to both correct me, and better yet, got him to go off and create a real implementation of Gantt charts in Notes views. Ulrich Krause made some of his own modifications to Nathan's work as well. Quite a community effort!

In case you missed it, this isn't just proof of concept, as Warren commented that they are actually using Gantt charts in his company's own internal pipeline database. Very cool! Thanks to everyone for your comments and contributions.

I don't have anything new to add to the discussion myself, but I did want to highlight one other technique that was brought to my attention. Noel Tigcal sent me a sample database that used a neat variation of the idea. Instead of using image resources for the bars, Noel uses the "█" symbol with @Repeat. This allows you to easily change the styling of the bar by modifying the text properties of the column. In the example database, Noel uses Arial Black as the font type.



Quite a smart idea and probably one of the easiest to implement, as you don't have to mess with graphics at all. Nice job, Noel...thanks for sharing!

With that, I'll leave this topic to rest. I'm not 100% convinced that true Gantt charts in Notes views are such a good idea (might be better relegated to a traditional project management tool or to a composite application), but still I hope you see that the underlying technique could have many possible uses.

Oh...by the way...in case you wondered how all this started, you can thanks Mr. Elgort for asking the question. :-)

Labels: , ,

permalink | leave a comment

Thursday, June 14, 2007

Show & Tell Thursday: Download Edition (My Cup Runneth Over)

Since I promised at both ILUG and Lotus Developer2007, I figured I better get some of my example databases out here for you to check out. I've also received a lot of e-mail with questions about various concepts over the last few months, so those might be included here as well. Finally, I'm including other databases I've made available in the past on this post as well, just so this becomes a comprehensive index of all the downloads to date. Read down through the list and see if there are any goodies you'd like to have. If you find anything that's of real use to you and you'd like to show your appreciation, you can go help Eileen and contribute to her cause!

As always, feel free to shoot me a mail (chris AT interfacematters.com) if you've got questions. I can't guarantee I'll answer right away (or that I'll know the answer), but I promise I will reply.

Disclaimer 1: All of these examples are proof of concepts. While many of the techniques come from applications I've developed and am using in production, I strip all extraneous code down to the bare minimum so you can focus on the mechanics of how the technique works. If you choose to use these ideas, please remember to use error checking and applicable standards based upon your company's best practices.

Disclaimer 2: I never said I was a good programmer! :-)

Disclaimer 3: Snausages...they really don't taste that good...









Building A Wizard Using Programmable Tabbed TablesI like Wizards...both the kind that can do cool magic tricks like turn your wife into a horny toad (no, you pervs...a horny toad) and the "really helpful from a usability standpoint" kind. Wizards are great for walking users through a multi-step process one task at a time. They're very easy to create with a programmable tabbed table you pull up in a dialog box. This demo shows you how.
Notes Is Like An Onion...It's Got LayersHere is the example database that I used for my Speedgeeking session at ILUG. We can stay up all night, swappin' manly stories about layers and in the morning...I'm makin' waffles!
Advanced User Interface Techniques for the Notes ClientThis was a demo database that I used for my session of the same name at Lotus Developer2007. It combines many of the past demos such as drag & drop, cascading menus, ordering a squishee (i.e. embedded editors) and the Super Burrito Configurator (woo hoo)!!!
Cool DocsThe demo that I put together on the plane on the way to Lotusphere. Just a quick idea of how a database experience can be changed in somewhat dramatic ways with just a little tweaking of the UI. Let your imagination be your guide! :-) Keep in mind that this is not a full solution...that's something I hope to work on it the future. This sample database also shows you how to easily collapse an embedded, single category view and includes code for creating "expand" and "collapse" functionality for the view as well. A nice usability touch for your embedded elements.
Fun With the DOM...Playing With The Action BarA sample snippet that demonstrates how you can use the Document Object Model to manipulate HTML elements. Since the Domino-generated action bar is just a table, you can get a hold of it and its child elements and do things like change the links, change the text based on the value of a field, turn it into a cascading menu, etc. Read the article and then follow along with the sample db.
Application Activity TrackingDon't forget this nifty little project on OpenNTF. Not only is the concept fairly useful, but what's nice about this one is the activity dashboard that summarizes all of the detail in an easy to read manner. On a related note, don't miss Kevin Pettitt's SuperNTF application, which combines this project and a host of others into a really nice framework for Lotus Notes.
Lotus Developer2007 CSS ExamplesFrom "Advanced CSS Techniques for Domino Web Applications". This zip file includes the stand-alone CSS and HTML files I was using to demonstrate some of the concepts like positioning and advanced selectors. The main Domino-based examples are in the demo database from the CD.



Now it's time to go record another segment for the Taking Notes podcast. That Bruce guy is a task master! :-)

See you on the flipside...

P.S. I'm using box.net to host these files. I tried their service quite a while back and it's really improved a lot. Very slick, easy to use interface. Kudos to them!


Technorati tags: ,

Labels: , , , , ,

permalink | leave a comment

Thursday, April 19, 2007

SnTT: Improving The User Experience With Wizards

I seem to get a lot of my blog post inspiration from questions I get asked by other developers. Someone asked me the other day about a dialog-based wizard in one of my applications. Specifically, they wanted to know how I displayed the dialog box without any buttons (OK, Cancel, etc.). I told them that this was a parameter that can be specified in the call to the dialog box and that it was an option introduced back in R5! As you can imagine, they were quite surprised. :-) It's certainly a good idea to take a look at the documentation once in a while. I've always thought that the Notes documentation (at least for development) was quite good. In fact, I tend to browse it from time to time just to see if there's something I've missed.

Anyway, I was going to use this opportunity to talk about designing a wizard with a programmatic tabbed table, but a quick search shows that some very smart people have already talked about this. So, rather than re-hash what Chris and Bill already detailed so well, I thought I'd just take a minute to explain the reason why I use a wizard-based approach in many applications.

I know it's hard to believe sometimes, but your users don't really care about the work of beauty that is your backend code. They're not interested in how it works, that you're using the latest ajax technique or that you've been able to optimize the database to fit 20% more data. Nope...they care about one thing when using your application...how easy it is to get in, get their work done and get out. I see my ultimate goal as a designer to make the UI of my applications so transparent that users "just get it". You want to try to get the interface out of the user's way so they can just perform the task at hand and get on with what actually makes the company money.

Especially in Lotus Notes, this is oftentimes easier said than done. Many interface elements are unintuitive (I'm talking about pre-Notes 8, of course), menus offer a confusing array of choices, the context menus are too long :-), etc. Whenever I am faced with a design that is going to require the user to either a) have some advanced knowledge of the Notes client interface or b) require several steps that would invariably mean that I would have to write documentation, I immediately turn my thoughts to building a wizard.

Let's take a very common example: importing data into Notes from Excel or some kind of file. We do this all the time. I decided a long time ago that never again do I want to try to explain the steps of importing data "the hard way" to a user. You know what I'm talking about.

1) Make sure you know where your spreadsheet is on your hard drive.
2) Go to the File menu and choose 'Import...'. No, the File menu. See it up there in the top left corner of your screen? No, below that little icon...Yep...that's it.
3) OK...now in that dialog box, select 'Lotus 1-2-3' as the file type. Wait, you did save your spreadsheet in 1-2-3 format, right?

We've all been there...

Enter the wizard. Wizards are a great device for walking a user through a multi-step process. In the case of importing data, I put the burden of work on myself as the developer rather than the user. In my mind, the user should be able to just say "Here's my file; now go do the work!". Yes, this entails more effort for the developer and I'll say yet again that I believe 100% that this extra effort is worth it. I understand we live in a RAD environment, but that doesn't excuse us from making the user experience the best it can be.

There's a million and one ways to do something like this, so I won't be displaying any code. I would like to show you some screens to illustrate what I'm talking about though.

In one of my applications, this is the first screen the user sees when they select the option to perform the monthly processing task.


Here, they are prompted to begin the import. Because of timing issues with the ERP system, they need to do this step manually, after they receive notification that the import file is available. Behind the scenes, my code is checking if the file is really there, verifying that it is valid, performing the actual import, etc.

Once the import is complete, I want the user to make sure that the data looks OK. It could be that the technical processes all worked correctly, but perhaps the data is bad for some reason. This step allows the user to apply their specific business knowledge to make sure it is safe to continue.


In the final step, the user kicks off the agent that does all the heavy lifting. Although there are many things going on here, the user's job is easy from a standpoint of interacting with the application. "Click three buttons and I'm good to go."


Yea!


Going back to the application I mentioned at the very beginning of this post, here are some screens from a dialog-based wizard.


Notice that removing the buttons from the dialog makes it look nice and clean and certainly "non-Notes like". (Hint...using simple photos in place of clipart or plain pages can help make a design look more polished and professional. Bonus points are given if the photo helps convey the meaning of the current context.).






In this particular application, it was necessary to allow the user to import e-mail addresses from their contacts and their mail file into the database. Again, we made the multiple steps involved to do this seem really easy to the user, which makes them really happy. Users perform this task infrequently, so an additional benefit with this app is that by having the wizard available, the user doesn't have to remember how they did the import the last time or (even worse) have to dig through their mail file to find the instructions!

Wrapping up, the purpose of this post, as with many of my rantings, is to try to encourage you to keep the user experience in mind as you build your applications. Off-loading the hard work to the technology is what makes us valuable and allows our users to be more productive and do value-added work. In the end, this is a win-win situation for us all.

Labels: , , ,

permalink | leave a comment

Thursday, April 05, 2007

SnTT: Programmable Tabbed Table Reset

I ran across two different applications yesterday that used programmable tabbed tables. One was a table in which the user could choose the tab and one did not display the tabs but allowed the user to pick between them with links. Both violated one of my cardinal interface rules in that you should avoid disorienting the user when presenting information to them. In both of these applications, the state of the tabbed table was retained when the document was saved. That is, if I was on the third tab of the table when I clicked the save button, the next time I opened the document, the tabbed table would still be on the third tab. Now, this could be perfectly good functionality in certain applications. Often it is great to take the user back to the exact place they were when they left off. This provides them with a mental reminder of what is was they were working on. In the case of the two applications in question, however, this was not desired functionality, especially since Notes provides no built-in mechanism for retaining the state information for a given user. In these applications, it makes more sense for the tabbed tables to display the first tab when a document is opened, since this tab contains the key metrics for the document. You see the problem here, right? If Joe opens the Account document and leaves off on tab 5, when I open the doc that is the information I will see. Since I'm not expecting this, there is a momentary feeling of being lost. Even though it is short-lived and I am able to quickly recover from the problem, leaving the user with an unsettling feeling, no matter how brief, does not engender a good user experience.

One of these applications, I'm embarrassed to say, was one of mine. This was merely a sin of omission on my part, since I have addressed this issue in many applications in the past, but I still felt a bit sheepish when I encountered it. Fortunately, the fix is very simple and is a good practice to get into if you are creating programmatic tabbed tables. Here's the scoop...

As you recall, you can make a programmable tabbed table by selecting the proper settings in the table properties dialog box.



To select a particular row in the tabbed table, you use the $table-name field and set it's value to the appropriate row. The $table-name field is created for you when you name the table and the row value is obtained from the row tag name. Both of these values are defined on the Table Programming tab.



You can see in the picture above that I've called the first tab "Tab1" and subsequent tabs are named in a similar fashion. Thus, at it's most basic, the formula to switch from this tab to the fourth tab in this table would be

@SetField("$NavTable" ; "Tab4");
@Command([RefreshHideFormulas])

This is a great feature, since it works in both read and edit mode. A programmable tabbed table has many uses. One example is displaying conditional information. I have an application in which usually only certain tabs should be shown, based on user input. By using a programmable tabbed table along with an outline, I provide a nice method to navigate among the various tabs, skipping over those that are not necessary. You can see an example screen below.



If you look at the document properties for a document with a programmable tabbed table, you'll actually see the $table-name field included with all of the other document fields.



Here's where the (potential) problem occurs. When a user edits the document, the current value of $NavTable is saved. So if I save and close when I'm on Tab4, that's the tab the next user will see when they open the document.

In order to avoid this problem, I simply use the code above in the query save event to set this field back to the first tab. Alternatively, you could reset the value when the document is opening. I needed to do this once when I was retrofitting some functionality into an existing application. Rather than mess with the QuerySave event (which had a huge mess of ugly LotusScript), I simply created a CFD field on the form called "SetTabbedTable". The formula for this field was:

@If(@IsDocBeingLoaded;
@SetField("$FinancialsTable"; "Tab0");
"")

This insured that the user was always presented with the first tab, whether in read mode or edit mode.

Well...that was a really simple tip and I probably provided way more background than you needed, but better to be thorough I say. In any event, this is an easy fix to apply and although it seems rather trivial, remember that the small things add up when we're on the way to user experience nirvana.

Labels: , ,

permalink | leave a comment

Wednesday, March 21, 2007

On Not Using Views

At the risk of losing this content in the post-Notes 8 beta buzz, I present to you a purely theoretical, completely opinionated post on working with views in the Notes client. :-)

If you've seen any of my presentations in the last year or have been reading my blog posts, you probably have heard me say something along the lines of "one of the great things you can do from a usability perspective is get rid of views in your applications." This statement usually elicits quizzical looks and I am often asked what I actually mean by this. This post is an attempt to explain this idea in a little more detail.

We all know that views are one of the biggest drains on performance in an application. The more views you have, the larger and slower the database becomes due to all of the view indices that need to be maintained. If you are an experienced developer, you've probably run across a few applications developed by Notes newbies that have a million views, one for every possible field in the database! :-) Heck, we all probably made at least one of those databases when we were starting out, unless an experienced developer was around to guide us and show us the error of our ways. I'm not going to go into the performance aspects of eliminating views here. Let's just take it as a given that the more you can reduce the number of views you have, the better off you'll be from a pure performance standpoint. Now, what about doing this from a user-centric point of view?

I often think of views as the "plumbing" of an application and as a plumber who cares about his craft, I want to hide the plumbing as much as possible. I like to use views where they make sense, such as providing users with a dynamic list of data within the database. However, when you take a step back and think about the work users have to do in your application, it's interesting to find that "browsing through a long list of documents to find the one I want" is not a part of that work. I like to use the analogy of Amazon.com. Technical limitations aside, what if you could build Amazon in Lotus Notes? Would you use views for your list of books, CDs, movies, etc.? I can just imagine the user scrolling through 1 million plus entries. Hmmm...probably not the most efficient way to find a good page turner. :-)

Business cases are often unique from one application to the next, but one of the fascinating things I found upon introspection on this topic is that I could probably redesign the UI of a great many of my Notes applications to eliminate user-centric views altogether. Most of the time, when a user enters one of my applications, they are doing so with a targeted objective, much like when I browse over to Amazon.com. I don't go to Amazon to "look around". If I want to do that, I'll head on down to my local bookstore. Instead, I use Amazon when I have a specific need. I know I can go there and almost always find what I need with a quick search. Herein lies the key, my friends. I can find what I want quickly and easily because the UI makes it so.

"So if you are not going to use views, how are users supposed to find their documents?", you may ask. The answer to that question is where your creativity as an application designer comes into play. Search is certainly one method available to you, although this generic solution is not always the most effective for business applications. If I think about the typical Notes app, it's some kind of workflow tracking system and the user probably has a key value that they are looking for when they open the database. It might be the customer name, a help ticket reference number, a specific date, etc. If you map out the work process that the user must go through, the most efficient way for them to target a document usually becomes clear. You can then use this information to design your UI around that fact. If the customer account number is the key for your CRM suite, then perhaps you should design a facility to open the account document by this number. This is simple as adding a field in a prominent place in the application UI, somewhere that is always visible and readily available, much like the search box at Amazon.com. You need to write a little code to find the document and then present it in the UI, but this is trivial. What's important here is that you have made the user much more efficient.

Back when I first started this blog, I talked about an application redesign I was involved with in which the general user had access to at most three documents in the whole database. Because of our corporate standards, this database looked like all the rest, with multiple views that might have made sense for the managers that had access to more that three documents, but they were completely wasted on the general end user. Even for the management team, the layout of the views was rather clunky and didn't allow them to find the information they were after easily. As I described in that old post, the whole process was reimagined, and the way users targeted documents was radically changed.



Instead of using views, the end user had three graphical representations of his documents and the color of the graphic would indicate if the document was completed or not. To open one of the document, the user had only to click the button. The users had no need for the views...they just needlessly complicated the UI. True to my form, if an element doesn't have an explicit purpose to be on the screen, it's outta there. Thus, no more views. I did the same thing for the managers (shown above), designing a slightly different implementation but still with a focus on what information they really needed and an emphasis on usability. Good UI design is all about simplicity and I think this case study is a great representation of that idea in action.

This is a good time to throw in one caveat. I shy away from using regular views when they are not necessary, but you know from past posts that I love working with embedded views. Embedded views are an important design element in Lotus Notes. Used properly, embedded views allow you to keep the user engaged in the context of their work, which is one of our goals in designing usable software.

So what are some of the guidelines you should follow when determining if you should build your database with user facing views?

Find vs. Browse: In my mind, the most important thing you need to do is map the user's work process as it relates to the application. This will allow you to answer the question of whether they will mostly browse for content or perform a targeted search process. If the majority of work will be targeted search, then you won't need many (or any) user-centric views. Instead, the UI should allow the user to open a specific document with a minimum number of clicks (e.g. enter the part number and click 'Go').




Don't make users do the hard work: If you use views in your application to summarize data, consider tossing the views in favor of a "report". I was involved in an extensive application redesign that was used by all managers around the world to get their monthly IT costs. Managers had to go into these enormous views, find their department and then reference all of their total spend. When I conducted user interviews based on this process, I found that the majority of managers just wanted to know one value. If they stayed within their budget for the month, they didn't care about anything else. Rather than continue the inefficient process that the old application used, I redesigned the application UI to make it a simple two step process...(1) enter your department and (2) get a nice summary document with the pertinent details. I created this document in the backend via LotusScript. It was a little more work for me, but the managers loved the time savings. I was able to make these modifications without changing the underlying plumbing of the database but made drastic usability improvements (and eliminated the use of views in the process)!




Learn to say No: A former colleague of mine was recently wondering about this concept and how to handle the users who demand everything. She said, "My customers always seem to want a million views - By status, by date, by requester, by priority, etc." My response to this is pretty much encapsulated in this article, but it brings up one important point which is true of software design in general. Sometimes, you just have to say 'No'. The reality is that we are the subject matter experts when it comes to application design, so we shouldn't just blindly do whatever the customer asks us to. It's in their best interest (and ours) to design simple, attractive and usable interfaces. Often this means having features fight for their lives. If the users are asking for a million views, question them on this. Ask them why they need them and what they are really looking to get. You may find that you actually do have to include all of these views and that's fine. But you might find that they are just used to Notes applications and think "that's the way it has to be done". Maybe they just want the totals at the bottom of the view. In that case, present the numbers in a nice dashboard or summary screen on the homepage and eliminate the view all together.

Look at other successful applications: As much as I sometimes hate the hype surrounding the term "Web 2.0", one thing is clear: There are lots of new applications out there that are redefining user interface development. Some of these apps, while perhaps somewhat trivial, are a joy to work with. Tom Duff talks about the importance of R&D...Rob & Duplicate :-) and I couldn't agree more. If you find an application that just works, spend some time analyzing it and ask yourself what it is about the app that turns you on. Then, go back to Notes and cry. Just kidding...actually, go back to the Notes client with an open mind. Allow yourself to be creative and see if you can replicate some of these great features in your design. If you look at many successful applications, they don't really have anything that looks like Notes views.

I hope this post has given you some food for thought. These concepts represent one of the tenants of Notes design that I've developed over the past few years and have seemed to serve me well. What do you think? As always, I welcome your comments and opinions.

Labels: , ,

permalink | leave a comment

Friday, February 23, 2007

More Embedded Editor Fun

While playing around with embedded editors today, I came up with another cool idea. When you have an embedded view and you want to programmatically change documents, what can you do? Sure, you can put some action buttons on the embedded view, but that's kind of limited. What if, instead, you wanted to do something like in Gmail, where you can select a pulldown value to trigger some action on a document? Actions aren't going to help you too much then. Enter the embedded editor. On your form, simply add the design elements you want to use to modify the document. In the example below, I have two buttons and a select box. All of the form elements are hidden when embedded except for this line. When the embedded view is wired to the embedded editor and the user selects the document in the view, the buttons and select box appear. The code behind the elements can be as simple or complex as you want...they are just running on the selected doc. A simple yet elegant solution...


Click on the graphic for an animated version of this technique in action.


Enjoy the weekend everyone!

Labels: , ,

permalink | leave a comment

Thursday, January 04, 2007

SnTT: Sometimes, It's About What's Not There

Well...it's the first Thursday of the new year, so what better way to kick it off than a show and tell post. Lotusphere always seems to energize people, so I'm looking forward to lots of great SnTT posts from fellow bloggers within the next few weeks.

Today, I'd like to address a topic that is fairly nebulous and certainly open to interpretation by the designer, but one that is very important in user interface development.

Have you ever seen a page or form in a Notes/web application that looked pretty good, but you could tell that something was off? Maybe you couldn't say exactly what, but you might have thought to yourself that, "it just doesn't look quite right". If you've encountered this (or perhaps find this in your own designs), then you've experienced the powerful effect that whitespace can have in an application UI. Whitespace (also referred to as negative space), is defined as the parts of a page that are absent of any content. What's really important about this is that whitespace isn't just blank space, but space that the designer purposefully left empty to provide an appealing and usable application interface.

In general, whitespace in UI design is used to:

*Logically separate content areas
*Provide margins and padding
*Aid in reducing strain on the eyes when reading text on the screen
*Help guide the user through the page's layout via subtle visual cues

In simple terms, whitespace can be thought of as the part of the design that helps frame the content and anchor the various elements on the page. Thoughtful use of whitespace can make a good design great, while poor use of whitespace can just make the page look empty or off balance. Whitespace is very important in defining a page's "flow", guiding the user's eye around the page, almost as if there was a dotted line trail saying, "follow me this way--->". As developers, there is often so much we need to fit into our designs...action buttons, fields, text containers, photos, etc. Our general tendency is to want to cram as much as possible into the available screen real estate. This is a bad idea, however, since it usually leads to visual overload for the user. The end result is that their productivity while using your application is diminished. Ever hear the saying that it's the notes that a musician doesn't play that is the true music (the exact quote...attributed to Claude Debussy is "Music is the space between the notes.")? Basically, that's what whitespace is to UI design.

First, lets look at a very simple example...some text within a box.



This is about as simple an example as we could get, yet it is extremely effective in demonstrating the power of whitespace. If you're like most people, just looking at the first box puts a strain on your eyes. This is because you are trying to process where the text begins in relationship to the boundary of the box. In addition, since the text runs up against the border, at every line beginning and ending point, it's like your eye is hitting a brick wall. In the second example, whitespace has been added to pad the text on all sides. This very simple change has made the text far more pleasant to read. You can just flow through the entire block of text very smoothly.

My blog design (which is basically hacked together from a blogger template...I'll update this someday I swear! :-) actually shows poor use of whitespace over on the right hand side of the page. The content, such as my photo, RSS feed, etc., butts right up against the edge of the column. Putting some whitespace in there would enhance the design. Here's a before and after mocked up with a graphics editor. The effect is subtle but effective.


Let's take a look at some more examples I've created. Two images are shown...the original and then one I've fixed up (click the picture to view it full size). Pick which one looks best to you in each set. See if you can identify the reason why one design stands out over the other.



OR


This example shows a personal document database I use to store good articles, blog entries, etc. that I come across. In the first screenshot, the design uses a standard view in the right-hand pane. Since the content extends beyond a single page, one problem I see is that the scroll bars make an ugly, off balancing border around my content. What would look much better is to have some simple whitespace (padding) around this element. With an easy design change (using an embedded view on a page), we get the second example, which has a much better flow. [ Yes, Nathan...I know...I'm going against Fitt's Law regarding the scroll bars ;-) but it looks better...especially with the thin scrollbars of the embedded view. ]

Even more readily apparent is the use of whitespace in the design of a Notes form. Take a look at these two snippets:



OR


This is from the Application Activity Tracking app that I have on OpenNTF. The first shows a dashboard screen that is all crammed together, something I see all too frequently in Notes databases. Notice how it is not readily apparent where sections begin and end. If you contrast that with the second screenshot, you'll see that adding a little whitespace around each bordered element makes them appear as discrete containers. Your eye naturally figures out and signals to your brain that each of these boxes actually represent something different. Again, a small change, but one that helps a great deal.

Here's one more...a form with a bunch of fields.



OR


In the first screen, there's lots of misuse of white space. First, there are many places where it's just absent (similar to the other examples) and makes the form look really crowded. Then, there are a couple examples of passive whitespace, which is also something you should try to avoid. Passive whitespace is whitespace that was not intentionally created by the developer. Rather, it's just space that is there due to the way the form is laid out. It's not really very extreme in this example, but it gives the sensation that something is missing. Usually, playing with the alignment and sizing of your layout can correct passive whitespace problems pretty easily.

[ Bonus points go to those of you that realized there's a more egregious error than whitespace on the first form...improper alignment! Those fields being misaligned creates a great sense of imbalance on the form (I'll talk about this more in another post). ]

So there you have it...a relatively simple overview of whitespace and it's use in design. As with much UI stuff, it is really just "advanced common sense". Readers who mostly like to sling code are probably rolling their eyes right now, but believe me, this stuff is important. I'm far from a great visual designer, but I endeavour to improve my skills with each assignment I have. Hopefully, as I try to introduce the basics of these concepts, you'll find some value in trying these techniques yourself. As always, I'd love to help you with any questions you might have. Feel free to leave a comment or drop me a line (chris@interfacematters.com).

Cheers!

Labels: ,

permalink | leave a comment