There Goes The Neighborhood
By now, I think almost everyone in the Notes community has heard of the Taking Notes Podcast
. This great show, hosted by the "effervescent" Bruce Elgort
and Julian Robichaux
is THE place to get all kinds of inside information about what is happening in the world of Lotus products, and in the technical community at large. If you haven't been following these guys, you have no excuses. Get on over there and start listening...you've got a lot of catching up to do!
Besides the fact that Bruce and Julian are such great guys, the reason for this plug is a little gratuitous self-promotion (and I already feel ashamed for doing so). I was honored with an invitation to start a new "Interface Matters" segment on the podcast. I'll be talking about interface design, usability, the user experience...basically all those goodies that I like discussing here. Of course, these will have a bit of a different slant, since it's a little difficult describing a screenshot over the radio. Unfortunately for you, this invite probably also means that the normally excellent quality of the podcast will begin going downhill! ;-)
I recorded the first part earlier this week and the segment debuts in Episode 60
, which was released today (wow...60 already!). Recording it was a lot harder than I expected and after getting through most of it, I learned I really need to have a more defined idea for where I'm going to go with things. Boy...can I ramble on. Hopefully it has some semblance of coherence. Anyway, once I finished, I shipped it off to Bruce for inclusion in the show. He told me he needed to "twiddle me in the garage" (or maybe it was "tweak me in GarageBand
")...something like that. I'm not really sure what happened, but it made me feel kind of dirty. :-D Far be it from me to tell a professional his job, though, so I went along with it. With some massive help from the "dweeb" filter in GarageBand, Bruce was able to make me sound bearable (at least one time through). Take a listen and judge the results for yourself.
Thanks again to Bruce and Julian for the opportunity!!! I guess whether or not there will be a second segment will depend on how much hate mail they get. :-D
Have a great weekend everyone!
Labels: podcasts, Taking Notes
permalink | leave a comment
Do You Bleed Yellow?
I've been thinking about evangelism a lot lately, mostly as it pertains to my livelihood...that is, what I do for a living every day. I've been working with Lotus technologies
for over 10 years now and I have to wonder sometimes if I need to be looking at other things. I'm certainly not adverse to learning new technologies. In fact, I think it is a great idea to expand your horizons. However, I'm passionate about Lotus because I've seen the transformative effect it can have when used correctly. Microsoft
understands the benefits of evangelism. In fact, they have people with this job title...how cool is that! They embrace their community of outspoken advocates and I have to pause and wonder why IBM
doesn't seem to do the same.
Merriam-Webster defines an evangelist as "an enthusiastic advocate". I think it is fair to say that many of us in the blogging community (not just those who blog, but those who read and comment as well) are "enthusiastic advocates". In my case, I consider it a personal mission inside my company to "spread the gospel" that is Lotus Notes. It was this zeal that led me to get involved with blogging, take a chance on presenting at professional conferences
(despite my fear of public speaking) and basically spend a lot of my free time trying to give back to the community. At work, I started the "Lotus Notes Power Hour"
, which was a volunteer effort to help people become more proficient with using the Lotus Notes client.
So the reason I've been giving this a lot of thought is the changing nature of the environment at work and what I see out in the business community at large. As many of you know, my company
is in the midst of a large merger with a former competitor
and with that brings many challenges. One of those challenges is that our technology landscape is morphing and I'm not sure what part Lotus technology will play in that space. Certainly we are evaluating the messaging platform, but this decision then tends to lead to a more thorough examination of the nature of collaboration within the group. Already we have been told that we want to start focusing our energies on building web-based applications (which is something we already do but usually make them client facing as well) and that leaves prospects for bringing in Notes 8 fairly bleak. It's in this time of uncertainly where it becomes even more important to be a "Lotus Evangelist" (boy I'd love to have that as a real job title!). What would thrill me would be some heavy-duty support to go along with my personal drive.
I'd really love to see Lotus reaching out more to the technical community to empower us to fight the good fight. I hate to use them as an example, but Microsoft has a great program called the Microsoft MVP
(Most Valuable Professional). Now just the title itself conveys the idea that "hey...these Microsoft guys think I'm alright". MVPs are "exceptional technical community leaders from around the world who are awarded for voluntarily sharing their high quality, real world expertise in offline and online technical communities. Microsoft MVPs are a highly select group of experts that represents the technical community's best and brightest, and they share a deep commitment to community and a willingness to help others." What an awesome thing to aspire to! I visit several forums and websites that are not IBM/Lotus related (Tablet PCs for one) and it is clear that the MVPs who participate have a wide breadth of knowledge and tools made available to them as a result of the program. They have subscriptions to MSDN, a relationship service that allows them to gain access to other users within and outside of Microsoft and even the MVP Global Summit
Now I may be completely off base, but I don't know of a similar program from Lotus. I know they provide a lot of support to business partners, but there are still many more of us out here that want to help get the message out. There are wonderful resources like OpenNTF
, the Taking Notes podcast
and others that are great examples of evangelism in action. Wouldn't it be incredible to see some serious commitment to these efforts from Lotus? How can we help them help us? Even within IBM itself, wouldn't you like to see more people with the title of "Lotus Evangelist"? A quick search on Google reveals 43,000 hits for "microsoft evangelist" (many more if you exclude the quotes) but only 28 for "lotus evangelist" and 237 for "ibm evangelist". Hmmm, that's quite a disconnect. Is it indicative of the industry as a whole? I often tell people that I "bleed yellow", but should I worry about hemorrhaging?
Don't get me wrong. I think many of the things Lotus and IBM have been doing lately are definitely steps in the right direction...giving Mary Beth Raven
and her team such prominence in the design of Notes 8, using her blog to reach out to the community during the development process, Bob Balaban
wanting to make Notes a "kick-ass appdev platform again"
. But...these are mostly efforts within IBM/Lotus itself. By enlisting the aid of the loyal masses, I think they could help make Bob's dream a reality in a much more profound and far-reaching way.
What do you think?
Labels: Evangelism, General, IBM, Lotus, Lotus Notes
permalink | leave a comment
What Would You Do?
Hi Friends! Today, I thought I'd take a little respite from writing my normally long-winded articles (translation: I'm wiped out from this weekend and I need a break! :-). Instead, I'm going to ask you to help me provide some ideas to another reader.
I got a great response from my post On Not Using Views
and I really appreciate all of the feedback and e-mails. In that thread, Keith asked a very relevant question. I started writing a reply, but then I thought that this was important enough to get some discussion going. Here's what he had to say:
"I've started creating apps with fewer views and experimenting with displaying data differently. But my problem is customers are wanting drop down boxes that may contain 200 choices. Once they pick a category from the drop down the pertinent documents are displayed in an embedded, single category view. Is there a better way to choose the categories other than having a drop down with 200+ choices? I've made it where they can start typing the category and it'll move accordingly, but it's still kind-of extreme."
This is a sticky wicket for sure, since he has presented a scenario that makes it difficult to definitively select one construct over another. Keith, you may never be able to come up with the perfect solution in this case, but here are some thoughts:
Can you change the taxonomy somewhat so that it will easier to make the relevant selection? For example, maybe the 200 choices are logically grouped into a subset of 10 or 20. You could then have two drop downs, one to select the main category and the second to pick the sub category. In that way, both sets of drop downs are relatively small and easy to handle.
Another thought is that maybe there is some info you could gather before the user opens the form that can help narrow down the list of choices. For example, perhaps your embedded view shows a list of sales calls by branch. On document open, ask the user what state the report is for and use that to show just the relevant branches for that state in the drop-down.
Sorry I don't have a better answer for you. Sometimes you are just stuck having to present a big list. There's nothing inherently wrong in this, however. In my mind, the key is to weigh this against the alternative and see which one works best. (Hint: Although it's tempting, don't try to answer this question yourself. This is the perfect time to enlist the aid of your customers and do some usability testing. Trust me, they'll tell you exactly what you need to know! :-)
So...perhaps some other people out there have come up with alternate solutions that might benefit Keith (and everyone else here). If you have an approach that you'd like to share, please leave a comment. Thanks in advance! Oh...and Keith, let us know what you end up doing.
Labels: UI design, Usability
permalink | leave a comment
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
. 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."
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: Show-n-tell-thursday, UI design, User Experience, wizards
permalink | leave a comment
Have You Tried Netflix?
is an incredible service, offering DVD rentals direct to your home via the U.S. mail. In my opinion, Netflix just does everything right. Their website is a testament to ease of use and creating an enjoyable user experience. They are constantly working on ways to improve all aspects of the customer relationship and the great thing about the company is that they recognize that that relationship extends far beyond the screen and the physical media in your DVD player. From e-mails that are short, sweet and respect my time to a no-brainer way to return movies, the Netflix folks obviously have a passion for making the movie lover's life easy. (Here's a neat short story
on the evolution of the Netflix envelope.)
Even if you're not a customer or don't plan to be one, I think it is worth checking out their site to see an example of a company that cares about the user experience.
If you enjoy movies and would like to give the service a test drive (highly recommended
), you can try it for free for one month by using this link
. This is two weeks longer than the usual free trial period, so it's a pretty nice deal. I don't get any credit or compensation for this, but I love the company enough to pass this along and sing their praises.
Kudos to you, Netflix...I'll be a customer for a long time to come.
Labels: General, Netflix
permalink | leave a comment
Programming Embedded Outlines
Last time, I talked a bit about programmable tabbed tables. They really come in handy and are a powerful interface construct, especially when used for certain tasks, such as progressive disclosure (more on that in a future post). Programmable tabbed tables make simple work of seemingly complex tasks, such as constructing a multi-step wizard to walk a user through a process. I think by now that most developers are familiar with the techniques behind programming a table, but did you know that you could use the same idea with embedded outlines? If not, please read on...
When you have an embedded outline and you click a link on the outline, you can, of course, have Notes highlight your selection. You:
"Yeah, ok, great...tell us something we don't know". Me:
"Wait...don't go away...this will be cool I promise. Did you also know that you can programmatically set the outline selection?"You:
"Duh...no need, it gets highlighted when I click it"Me:
"Ah...that's true. But...what if you go about selecting the element associated with a certain outline element WITHOUT clicking on the outline?"You:
(in a Homer Simpson-esque way)* "Hmmm...go on..."
Here's the deal. I've had several developers ask me through the years why there is a 'Name' property for an embedded outline. This is the one I'm referring to:
The name in this case can be used programmatically, just like in a tabbed table. When you place the outline on the form and create a document based on that form, a new field called "$OUTLINE_NAME" (where OUTLINE_NAME is the name you provide in the embedded outline properties) is added to the document. This field holds a number that corresponds to the outline entry currently selected. The outline entries are labeled 1 through (max number of entries)
in the order that they appear in the design (see below).
Thus, if you wanted to highlight the fourth entry in the embedded outline, your code would be a simple:
At this point, you might still be wondering why you would actually use this. Let me show you a scenario from one of my production applications that should help illustrate the idea. In the last post, I told you about an application in which I use a programmable tabbed table and embedded outline to display various sections to a user. The sections on this form can vary based on document status, user input, etc. The embedded outline is used to make navigating through the sections easy. That is, if the user wants to jump from the first section to the last, they can just click the appropriate link in the outline. But many times the user wants to progress through the form in the logical way that was designed based on business process rules. In this case, the user is certainly free to use the outline, but we have also provided them with simple 'Next and 'Previous' links that allow them to navigate one section at a time (see the screenshot below).
In order to make sure that the appropriate link is highlighted in the embedded outline (which is another visual reminder to the user of where they are) when these links are triggered, we make use of the programmable nature of the outline using the simple formula language snippet detailed earlier.
I think this is pretty slick on Lotus' part. What about you?
Don't forget about the fact that it might be desirable to reset the outline highlight to the first entry the next time the user opens the document (as I discussed for programmable tables in my last post). You can handle this scenario in the same way. Either set the $OUTLINE_NAME field back to 1 when the user saves the document or do so when the document is being loaded in the UI.
Finally, there's one little 'GOTCHA' to be aware of when using this technique. The number you use to highlight a particular outline entry can actually change
based on the entries that are displayed in the UI, so you have to account for this in your code. For example, assume that you have an outline with six entries. In a particular scenario, the first two entries on the outline are hidden. In this situation, the third entry is considered entry number 1 as far as programmatic access is concerned. This can be a bit tricky if you are showing and hiding things a lot. If you are careful and put some thought into the way the entries are arranged on your outline, this usually isn't too bad...nothing a simple @If can't handle, but it's important you know about it so you don't end up pulling out your hair!
OK...that's it...another short and sweet post. If you weren't already aware of this technique, I hope it comes in handy for you some time in the future. As always, feel free to leave your comments or drop me a line if you have any questions. Cheers!
*Disclaimer: I am not implying that my readers are like Homer Simpson...I just like when he says that! :-D
Labels: outlines, UI design, Usability, User Experience
permalink | leave a comment
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");
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:
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: Show-n-tell-thursday, Usability, User Experience
permalink | leave a comment
Can You Read This?
I have to thank my mother-in-law for this post (thanks, Joyce! :-) It's very cool. Let me know how you make out. I'd be especially interested to see if people with English as a second language have a much harder time with this than native speakers.
fiyuo cna raed tihs, yuo hvae a sgtrane mnid too. Cna yuo raed tihs ? Olny 55 plepoe out of 100 can.
i cdnuolt blveiee taht I cluod aulaclty uesdnatnrd waht I was rdanieg . The phaonmneal pweor of the hmuan mnid, aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it dseno't mtaetr in waht oerdr the ltteres in a wrod are, the olny iproamtnt tihng is taht the frsit and lsat ltteer be in the rghit pclae . The rset can be a taotl mses and you can sitll raed it whotuit a pboerlm. Tihs is bcuseae the huamn mn id deos not raed ervey lteter by istlef, but the wrod as a wlohe . Azanmig huh? yaeh and I awlyas tghuhot slpeling was ipmorantt!
Labels: Fun, General, Stuff
permalink | leave a comment